| From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
|---|---|
| To: | Will Mortensen <will(at)extrahop(dot)com>, Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Marco Slot <marco(dot)slot(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, marco(at)citusdata(dot)com, Yvonne Chen <yvonne(at)extrahop(dot)com>, Jacob Speidel <jacob(at)extrahop(dot)com> |
| Subject: | Re: Exposing the lock manager's WaitForLockers() to SQL |
| Date: | 2024-01-06 12:00:08 |
| Message-ID: | 79c04acdc0dd464fc6e22fb22778bbc316dbb259.camel@cybertec.at |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, 2024-01-06 at 02:57 -0800, Will Mortensen wrote:
> Simplified the code and docs, and rewrote the example with more prose
> instead of PL/pgSQL, which unfortunately made it longer, although it
> could be truncated. Not really sure what's best...
I thought about this idea, and I have some doubts.
WAIT FOR LOCKERS only waits for transactions that were holding locks
when the statement started. Transactions that obtailed locks later on
are ignored. While your original use case is valid, I cannot think of
any other use case. So it is a special-purpose statement that is only
useful for certain processing of append-only tables.
Is it worth creating a new SQL statement for that, which could lead to
a conflict with future editions of the SQL standard? Couldn't we follow
the PostgreSQL idiosyncrasy of providing a function with side effects
instead?
Yours,
Laurenz Albe
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bharath Rupireddy | 2024-01-06 14:04:15 | Re: introduce dynamic shared memory registry |
| Previous Message | Will Mortensen | 2024-01-06 10:57:04 | Re: Exposing the lock manager's WaitForLockers() to SQL |