On Thu, May 30, 2024 at 12:01 AM Will Mortensen <w...@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. :-)
