Re: Problems around compute_query_id
От | Julien Rouhaud |
---|---|
Тема | Re: Problems around compute_query_id |
Дата | |
Msg-id | 20210412065659.o4pnb7sknaxjzc42@nol обсуждение исходный текст |
Ответ на | Problems around compute_query_id (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Problems around compute_query_id
Re: Problems around compute_query_id |
Список | pgsql-hackers |
On Mon, Apr 12, 2021 at 03:12:40PM +0900, Michael Paquier wrote: > Hi all, > > Starting a new thread as the one that has introduced compute_query_id > is already long enough. > > 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. > 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?
В списке pgsql-hackers по дате отправления: