From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Notice lock waits |
Date: | 2016-08-05 19:58:53 |
Message-ID: | CAMkU=1ySVOf9RhkorYDVsuJiAtu4OUcQYT0ZgRLU50GE4AVs9Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Aug 5, 2016 at 12:17 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Jeff Janes <jeff(dot)janes(at)gmail(dot)com> writes:
>> I have it PGC_SUSET because it does send some tiny amount of
>> information about the blocking process (the PID) to the blocked
>> process. That is probably too paranoid, because the PID can be seen
>> by anyone in the pg_locks table anyway.
>
> Why not just leave out the PID? I think it's often far too simplistic
> to blame a lock wait on a single other process, anyway.
It actually wasn't including the PID anyway, as the
errdetail_log_plural was not getting passed to the client.
So I changed it to PGC_USERSET, didn't attempt to include details that
won't be sent anyway (although it would be nice for a superuser to be
able to see the statement text of the blocker, but that is a bigger
issue than I am willing to deal with here) and have removed a memory
leak/bug I introduced by foolishly trying to use 'continue' to avoid
introducing yet another layer of nesting.
Cheers,
Jeff
Attachment | Content-Type | Size |
---|---|---|
notice_lock_waits-V02.patch | application/octet-stream | 8.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2016-08-05 20:22:27 | Add hint for people who place EXECUTE USING arguments in parentheses (in plpgsql) |
Previous Message | Bruce Momjian | 2016-08-05 19:26:15 | Re: Heap WARM Tuples - Design Draft |