Re: Problems around compute_query_id - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: Problems around compute_query_id
Date
Msg-id 20210415074359.z3aqxkfv4p2gi4cp@nol
Whole thread Raw
In response to Re: Problems around compute_query_id  (Julien Rouhaud <rjuju123@gmail.com>)
Responses Re: Problems around compute_query_id  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Mon, Apr 12, 2021 at 02:56:59PM +0800, Julien Rouhaud wrote:
> I think we should simply document that %Q is not compatible with
> log_statements.

Hearing no objection I documented that limitation.

> 
> > While making the feature run on some test server, I have noticed that
> > %Q would log some garbage query ID for autovacuum workers that's kept
> > around.  That looks wrong.
> 
> I've not been able to reproduce it, do you have some hint on how to do it?
> 
> Maybe setting a zero queryid at the beginning of AutoVacWorkerMain() could fix
> the problem?

It turns out that the problem was simply that some process can inherit a
PgBackendStatus for which a previous backend reported a queryid.  For processes
like autovacuum process, they will never report a new identifier so they
reported the previous one.  Resetting the field like the other ones in
pgstat_bestart() fixes the problem for autovacuum and any similar process.

Attachment

pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Replication slot stats misgivings
Next
From: Michael Paquier
Date:
Subject: Re: [PATCH] expand the units that pg_size_pretty supports on output