Re: expose parallel leader in CSV and log_line_prefix

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Justin Pryzby <pryzby(at)telsasoft(dot)com>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: expose parallel leader in CSV and log_line_prefix
Date: 2020-07-17 05:01:21
Message-ID: 20200717050121.GD29811@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2020-07-17 05:03:18 Re: Stale external URL in doc?
Previous Message Andrey V. Lepikhov 2020-07-17 04:23:19 Re: Partitioning and postgres_fdw optimisations for multi-tenancy