From: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: expose parallel leader in CSV and log_line_prefix |
Date: | 2020-07-17 05:34:54 |
Message-ID: | CAOBaU_ZMcUGp2cyY-VThxK5HanNkgynx2j-ptHeHVARNs6QKsw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On Fri, Jul 17, 2020 at 7:01 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> 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.
I had the same concern and was thinking about this approach too.
Another argument is that IIUC any log emitted due to
log_min_duration_statement wouldn't see the backend as executing a
parallel query, since the workers would already have been shut down.
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2020-07-17 05:45:10 | Re: Added tab completion for the missing options in copy statement |
Previous Message | tsunakawa.takay@fujitsu.com | 2020-07-17 05:21:05 | RE: Transactions involving multiple postgres foreign servers, take 2 |