Re: Add “FOR UPDATE NOWAIT” lock details to the log.

Thank you for your comments.

> + Currently, only lock failures due to <literal>NOWAIT</literal> are
> +        supported.  The default is <literal>off</literal>.  Only
> superusers
>
> This GUC also affects SKIP LOCKED, so that should be documented.

I overlooked it... I have revised the document with SKIP LOCKED.

> If CollectLockHoldersAndWaiters() is used only in proc.c,
> it should be made a static function.
>
> +/*
> + * we loop over the lock's procLocks to gather a list of all
> + * holders and waiters. Thus we will be able to provide more
> + * detailed information for lock debugging purposes.
>
> For the source comment of CollectLockHoldersAndWaiters(),
> could you follow the style of other functions in proc.c?
>
> Why is the logic to report lock holders and waiters implemented within
> JoinWaitQueue()?
> Wouldn't it be better placed right after JoinWaitQueue() is called in
> LockAcquireExtended(), similar to DeadLockReport()? One issue with
> the current implementation is that partitionLock is held in exclusive
> mode
> while collecting and reporting lock holders and waiters. If the logic
> is moved
> after JoinWaitQueue() in LockAcquireExtended(), lock holders and
> waiters could be
> processed after releasing partitionLock. Note, however, that
> partitionLock might
> still need to be taken again in shared mode during the collection.

Indeed.

I moved the logic to report lock holders and waiters after JoinWaitQueue().

Regards,