On Fri, Aug 5, 2016 at 12:17 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Jeff Janes <jeff.ja...@gmail.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
notice_lock_waits-V02.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
