From: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> |
Subject: | Re: Problems around compute_query_id |
Date: | 2021-04-22 08:37:35 |
Message-ID: | 20210422083735.hz7n3pzkua5tpgmb@nol |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Apr 20, 2021 at 12:59:10PM -0400, Bruce Momjian wrote:
> On Thu, Apr 15, 2021 at 03:43:59PM +0800, Julien Rouhaud wrote:
> > 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.
>
> I slightly adjusted the patch and applied it. Thanks. I think this
> closes all the open issues around query_id. :-)
Thanks a lot Bruce! There was also [1], but Michael already committed the
proposed fix, so I also think that all open issues for query_id are not taken
care of!
[1]: https://postgr.es/m/CAJcOf-fXyb2QiDbwftD813UF70w-+BsK-03bFp1GrijXU9GQYQ@mail.gmail.com
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Pryzby | 2021-04-22 08:56:14 | Re: TRUNCATE on foreign table |
Previous Message | Kyotaro Horiguchi | 2021-04-22 08:31:34 | Some doubious messages |