On Thu, Jul 16, 2020 at 10:55:45PM -0400, Alvaro Herrera wrote:
> Oh, ugh, I don't like that part much. If you run connections through a
> connection pooler, it's going to be everywhere. Let's put it there only
> if the connection *is* running a parallel query, without being too
> stressed about the startup and teardown sequence.
Hmm. Knowing if a leader is actually running parallel query or not
requires a lookup at lockGroupMembers, that itself requires a LWLock.
I think that it would be better to not require that. So what if
instead we logged %P only if Myproc has lockGroupLeader set and it
does *not* match MyProcPid? In short, it means that we would get the
information of a leader for each worker currently running parallel
query, but that we would not know from the leader if it is running a
parallel query or not at the moment of the log. One can then easily
guess what was happening on the leader by looking at the logs of the
backend matching with the PID the workers are logging with %P.
--
Michael
