| From: | Will Mortensen <will(at)extrahop(dot)com> |
|---|---|
| To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Cc: | Marco Slot <marco(dot)slot(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Jacob Speidel <jacob(at)extrahop(dot)com>, Yvonne Chen <yvonne(at)extrahop(dot)com>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, vignesh C <vignesh21(at)gmail(dot)com> |
| Subject: | Re: Exposing the lock manager's WaitForLockers() to SQL |
| Date: | 2024-07-22 06:46:51 |
| Message-ID: | CAMpnoC61bX3TbX8=-vPspBxxHU6w0Zjo+hghz5H8xhg-vS=b=g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, May 30, 2024 at 12:01 AM Will Mortensen <will(at)extrahop(dot)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. :-)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2024-07-22 06:57:26 | Re: Slow catchup of 2PC (twophase) transactions on replica in LR |
| Previous Message | Pavel Stehule | 2024-07-22 06:37:22 | Re: proposal: schema variables |