Re: expose parallel leader in CSV and log_line_prefix
От | Julien Rouhaud |
---|---|
Тема | Re: expose parallel leader in CSV and log_line_prefix |
Дата | |
Msg-id | CAOBaU_ZMcUGp2cyY-VThxK5HanNkgynx2j-ptHeHVARNs6QKsw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: expose parallel leader in CSV and log_line_prefix (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: expose parallel leader in CSV and log_line_prefix
Re: expose parallel leader in CSV and log_line_prefix |
Список | pgsql-hackers |
Hi, On Fri, Jul 17, 2020 at 7:01 AM Michael Paquier <michael@paquier.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.
В списке pgsql-hackers по дате отправления: