Re: Exposing the lock manager's WaitForLockers() to SQL - Mailing list pgsql-hackers

From Will Mortensen
Subject Re: Exposing the lock manager's WaitForLockers() to SQL
Date
Msg-id CAMpnoC61bX3TbX8=-vPspBxxHU6w0Zjo+hghz5H8xhg-vS=b=g@mail.gmail.com
Whole thread Raw
In response to Re: Exposing the lock manager's WaitForLockers() to SQL  (Will Mortensen <will@extrahop.com>)
List pgsql-hackers
On Thu, May 30, 2024 at 12:01 AM Will Mortensen <will@extrahop.com> wrote:
> FWIW, another solution might be to directly expose the functions that
> WaitForLockers() calls, namely GetLockConflicts() (generalized to
> GetLockers() in the first patch) to identify the transactions holding
> the locks, and VirtualXactLock() to wait for each transaction to
> commit or roll back. That would be more complicated for the client but
> could be more broadly useful. I could investigate that further if it
> seems preferable.

We will look further into this. Since the main advantage over polling
the existing pg_locks view would be efficiency, we will try to provide
more quantitative evidence/analysis of that. That will probably want
to be a new thread and CF entry, so I'm withdrawing this one.

Thanks again for all the replies, and to Robert for your off-list
feedback and letting me bend your ear in Vancouver. :-)



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: proposal: schema variables
Next
From: Amit Kapila
Date:
Subject: Re: Slow catchup of 2PC (twophase) transactions on replica in LR