Hi, On Mon, Apr 12, 2021 at 02:56:59PM +0800, Julien Rouhaud wrote: > On Mon, Apr 12, 2021 at 03:12:40PM +0900, Michael Paquier wrote: > > Fujii-san has reported on Twitter that enabling the computation of > > query IDs does not work properly with log_statement as the query ID is > > calculated at parse analyze time and the query is logged before that. > > As far as I can see, that's really a problem as any queries logged are > > combined with a query ID of 0, and log parsers would not really be > > able to use that, even if the information provided by for example > > log_duration gives the computed query ID prevent in pg_stat_activity. > > I don't see any way around that. The goal of log_statements is to log all > syntactically valid queries, including otherwise invalid queries. For > instance, it would log > > SELECT notacolumn; > > and there's no way to compute a queryid in that case. I think that > log_statements already causes some issues with log parsers. At least pgbadger > recommends to avoid using that: > > "Do not enable log_statement as its log format will not be parsed by > pgBadger." > > I think we should simply document that %Q is not compatible with > log_statements.
What about log_statement_sample_rate ? Does compute_query_id have the same problem with that? Michael -- Michael Banck Projektleiter / Senior Berater Tel.: +49 2166 9901-171 Fax: +49 2166 9901-100 Email: michael.ba...@credativ.de credativ GmbH, HRB Mönchengladbach 12080 USt-ID-Nummer: DE204566209 Trompeterallee 108, 41189 Mönchengladbach Geschäftsführung: Dr. Michael Meskes, Sascha Heuer Unser Umgang mit personenbezogenen Daten unterliegt folgenden Bestimmungen: https://www.credativ.de/datenschutz
