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

Поиск
Список
Период
Сортировка
От Will Mortensen
Тема Re: Exposing the lock manager's WaitForLockers() to SQL
Дата
Msg-id CAMpnoC738G5Yyf9=rb9nGBKbAOjYx_oex6zijOJW_0SQ6_BWRg@mail.gmail.com
обсуждение исходный текст
Ответ на 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
I realized that for our use case, we'd ideally wait for holders of
RowExclusiveLock only, and not e.g. VACUUM holding
ShareUpdateExclusiveLock. Waiting for lockers in a specific mode seems
possible by generalizing/duplicating WaitForLockersMultiple() and
GetLockConflicts(), but I'd love to have a sanity check before
attempting that. Also, I imagine those semantics might be too
different to make sense as part of the LOCK command.

Alternatively, I had originally been trying to use the pg_locks view,
which obviously provides flexibility in identifying existing lock
holders. But I couldn't find a way to wait for the locks to be
released / transactions to finish, and I was a little concerned about
the performance impact of selecting from it frequently when we only
care about a subset of the locks, although I didn't try to assess that
in our particular application.

In any case, I'm looking forward to hearing more feedback from
reviewers and potential users. :-)



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

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: Impact of checkpointer during pg_upgrade
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: pg_upgrade and logical replication