Thanks for your reviewing and comments!
On 2021-01-14 12:39, Ian Lawrence Barwick wrote:
> Looking at the code, this happens as the wait start time is being
> recorded in
> the lock record itself, so always contains the value reported by the
> latest lock
> acquisition attempt.
I think you are right and wait_start should not be recorded
in the LOCK.
On 2021-01-15 11:48, Ian Lawrence Barwick wrote:
> 2021年1月15日(金) 3:45 Robert Haas <robertmhaas@gmail.com>:
>
>> On Wed, Jan 13, 2021 at 10:40 PM Ian Lawrence Barwick
>> <barwick@gmail.com> wrote:
>>> It looks like the logical place to store the value is in the
>> PROCLOCK
>>> structure; ...
>>
>> That seems surprising, because there's one PROCLOCK for every
>> combination of a process and a lock. But, a process can't be waiting
>> for more than one lock at the same time, because once it starts
>> waiting to acquire the first one, it can't do anything else, and
>> thus
>> can't begin waiting for a second one. So I would have thought that
>> this would be recorded in the PROC.
>
> Umm, I think we're at cross-purposes here. The suggestion is to note
> the time when the process started waiting for the lock in the
> process's
> PROCLOCK, rather than in the lock itself (which in the original
> version
> of the patch resulted in all processes with an interest in the lock
> appearing
> to have been waiting to acquire it since the time a lock acquisition
> was most recently attempted).
AFAIU, it seems possible to record wait_start in the PROCLOCK but
redundant since each process can wait at most one lock.
To confirm my understanding, I'm going to make another patch that
records wait_start in the PGPROC.
Regards,
--
Atsushi Torikoshi
