On Fri, Aug 5, 2016 at 12:17 PM, Tom Lane <[email protected]> wrote: > Jeff Janes <[email protected]> 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 ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
