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

Поиск
Список
Период
Сортировка
От Laurenz Albe
Тема Re: Exposing the lock manager's WaitForLockers() to SQL
Дата
Msg-id 79c04acdc0dd464fc6e22fb22778bbc316dbb259.camel@cybertec.at
обсуждение исходный текст
Ответ на Re: Exposing the lock manager's WaitForLockers() to SQL  (Will Mortensen <will@extrahop.com>)
Ответы Re: Exposing the lock manager's WaitForLockers() to SQL  (Will Mortensen <will@extrahop.com>)
Список 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Will Mortensen
Дата:
Сообщение: Re: Exposing the lock manager's WaitForLockers() to SQL
Следующее
От: Bharath Rupireddy
Дата:
Сообщение: Re: introduce dynamic shared memory registry