Re: bug reapper: Empty query_id in pg_stat_activity
От | Michael Paquier |
---|---|
Тема | Re: bug reapper: Empty query_id in pg_stat_activity |
Дата | |
Msg-id | aLPXdwfnXRXONzMS@paquier.xyz обсуждение исходный текст |
Ответ на | Re: bug reapper: Empty query_id in pg_stat_activity (Greg Sabino Mullane <htamfids@gmail.com>) |
Ответы |
Re: bug reapper: Empty query_id in pg_stat_activity
|
Список | pgsql-bugs |
On Thu, Aug 28, 2025 at 08:42:32AM -0400, Greg Sabino Mullane wrote: > This just moves the race condition around a little - you can end up with a > query that does not agree with its query_id. The query ID assignment in a backend entry has always been kind of a pessimistic concept: the backend sets it when it knows about it. Note that there are a few cases with the extended query protocol for execute messages, where the query ID can be set only when we're in the executor start path. Always reporting the previous query ID if the current one is not set is also breaking an existing property of the current implementation: a NULL query ID means that we are in the process of running a query. The proposed patch would always show a query ID, even if the backend has begun running an entire different query, for which the query ID would be assigned later, just we don't know about it yet. In short, I don't think that there's anything to fix here. The proposed patch is breaking some assumptions that the current backend implementation relies on. -- Michael
Вложения
В списке pgsql-bugs по дате отправления: