From: | Ian Lawrence Barwick <barwick(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | torikoshia <torikoshia(at)oss(dot)nttdata(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: adding wait_start column to pg_locks |
Date: | 2021-01-15 02:48:34 |
Message-ID: | CAB8KJ=idS0m_+65d2ujjjZj5DSwpYYV3XoHMwr-UZ-OFs3Mb4Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2021年1月15日(金) 3:45 Robert Haas <robertmhaas(at)gmail(dot)com>:
> On Wed, Jan 13, 2021 at 10:40 PM Ian Lawrence Barwick <barwick(at)gmail(dot)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).
As mentioned, I hadn't really ever looked at the lock code before so might
be barking up the wrong forest.
Regards
Ian Barwick
--
EnterpriseDB: https://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2021-01-15 03:02:56 | Re: Remove PG_SHA*_DIGEST_STRING_LENGTH from sha2.h |
Previous Message | tsunakawa.takay@fujitsu.com | 2021-01-15 02:47:12 | RE: POC: postgres_fdw insert batching |