From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Greg Sabino Mullane <htamfids(at)gmail(dot)com> |
Cc: | Srinath Reddy Sadipiralla <srinath2133(at)gmail(dot)com>, "duomi(dot)peng" <duomi(dot)peng(at)qq(dot)com>, pgsql-bugs <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: bug reapper: Empty query_id in pg_stat_activity |
Date: | 2025-08-31 05:02:47 |
Message-ID: | aLPXdwfnXRXONzMS@paquier.xyz |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Korotkov | 2025-08-31 22:13:47 | Re: BUG #19031: pg_trgm infinite loop on certain cases |
Previous Message | Michael Paquier | 2025-08-31 04:53:50 | Re: Broken PQtrace CopyData display |