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

Поиск
Список
Период
Сортировка
От Will Mortensen
Тема Re: Exposing the lock manager's WaitForLockers() to SQL
Дата
Msg-id CAMpnoC7miH7cGo_9xx888mWw+Xen6Drwb93TS0v9gjJxTrf4jw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Exposing the lock manager's WaitForLockers() to SQL  (Andres Freund <andres@anarazel.de>)
Ответы Re: Exposing the lock manager's WaitForLockers() to SQL  (Will Mortensen <will@extrahop.com>)
Список pgsql-hackers
Hi Andres,

On Thu, Jan 12, 2023 at 7:49 PM Andres Freund <andres@anarazel.de> wrote:
> Consider a scenario like this:
>
> tx 1: acquires RowExclusiveLock on tbl1 to insert rows
> tx 2: acquires AccessShareLock on tbl1
> tx 2: WaitForLockers(ShareRowExclusiveLock, tbl1) ends up waiting for tx1
> tx 1: truncate tbl1 needs an AccessExclusiveLock

Oh of course, thanks.

Is it even necessary to take the AccessShareLock? I see that one can call e.g.
RangeVarGetRelidExtended() with NoLock, and from the comments it seems
like that might be OK here?

Did you have any remaining concerns about the suitability of WaitForLockers()
for the use case?

Any thoughts on the syntax? It seems like an option to LOCK (like Marco
suggested) might be simplest to implement albeit a little tricky to document.

Supporting descendant tables looks straightforward enough (just collect more
locktags?). Views look more involved; maybe we can avoid supporting them?



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

Предыдущее
От: vignesh C
Дата:
Сообщение: Re: Support logical replication of DDLs
Следующее
От: Noah Misch
Дата:
Сообщение: Re: allowing for control over SET ROLE