Re: Problems around compute_query_id - Mailing list pgsql-hackers

From Michael Banck
Subject Re: Problems around compute_query_id
Date
Msg-id 6073f4a8.1c69fb81.19c4a.5663@mx.google.com
Whole thread Raw
In response to Re: Problems around compute_query_id  (Julien Rouhaud <rjuju123@gmail.com>)
Responses Re: Problems around compute_query_id  (Julien Rouhaud <rjuju123@gmail.com>)
List pgsql-hackers
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.banck@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



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Truncate in synchronous logical replication failed
Next
From: Julien Rouhaud
Date:
Subject: Re: Problems around compute_query_id