Re: Problems around compute_query_id

Поиск
Список
Период
Сортировка
От Julien Rouhaud
Тема Re: Problems around compute_query_id
Дата
Msg-id 20210422083735.hz7n3pzkua5tpgmb@nol
обсуждение исходный текст
Ответ на Re: Problems around compute_query_id  (Bruce Momjian <bruce@momjian.us>)
Список 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




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Kyotaro Horiguchi
Дата:
Сообщение: Some doubious messages
Следующее
От: Justin Pryzby
Дата:
Сообщение: Re: TRUNCATE on foreign table