darold / pgbadger

A fast PostgreSQL Log Analyzer
http://pgbadger.darold.net/
PostgreSQL License
3.51k stars 349 forks source link

when does the option multiline is useful ? from the documentation it isn't clear #686

Closed massimo-sala closed 3 years ago

massimo-sala commented 3 years ago

Hi

I have configured our postgres instances to minimize the output of multiline statements:

log_autovacuum_min_duration = -1
log_error_verbosity = terse

Postgres logs thru stderr, so we haven't bugs introduced by syslog max size of messages.

Still we have occasionally multiline statements ... is this a problem for pgbadger ?

2021-08-18 15:15:03 CEST [3294]: db=atti,user=atti,client=127.0.0.1 STATEMENT:  INSERT INTO EXP_XML_ITER(CODESTR,PR_COD_PRAT,GI_COD_ELECOD,GI_DES_ELE,GI_COD_ESITO,M1_TAB_DES,GI_DAT_FIN, M1$
                    UNION
                    SELECT A.CODESTR, A.T_PRATICA_ID,B.ACTIVITYDEFINITIONID, B.NAME , 'ESE','Eseguito',B.GI_DAT_FIN,
etc...

Pls note: the statement is truncated at etc... it continues on more lines.

I feel bad about using --multiline, I don't want to loose the reporting of these statements.

I read the documentation but I cannot grasp it:

-M | --no-multiline    : do not collect multiline statement to avoid garbage
                                 especially on errors that generate a huge report.

Questions: 1) Darold can you please explain in detail when the option should be used ? What do you mean with garbage ?

2) Can pgbadger parse the multiline statements (like the example) without problems?

3) Feature request: can pgbadger emit a warning if there is any problem ? Example: I cannot parse some multiline statements, please use the option --multiline

darold commented 3 years ago

About 3. you have the debug mode ( -v ) that will show the lines that pgbadger can not parse correctly.

The --no-multiline option is to be used in case you see garbage in query reported, I mean data that are not part of the original query. This could be useful in some extremely rare situation.

Actually I don't understand why you are trying to avoid as much as possible multiline in your log file. What is the exact problem you are trying to fix? Keeping log_error_verbosity to default is better unless your applications are generating a huge amount of errors.

massimo-sala commented 3 years ago

Darold: why you are trying to avoid as much as possible multiline in your log file

Because the application sometimes creates INSERT statements with really huge text values (Mbytes).

Pls consider the question from another point of view. What features do we lose using --multiline ?

darold commented 3 years ago

With --multiline you will just have the first line of the multiline statement reported. But normally your INSERT statement should be truncated to 100 000 characters and if you want it to be truncated to less use the --maxlength option