Re: Exposing the lock manager's WaitForLockers() to SQL

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. :-)