Re: Exposing the lock manager's WaitForLockers() to SQL - Mailing list pgsql-hackers

From Will Mortensen
Subject Re: Exposing the lock manager's WaitForLockers() to SQL
Date
Msg-id CAMpnoC738G5Yyf9=rb9nGBKbAOjYx_oex6zijOJW_0SQ6_BWRg@mail.gmail.com
Whole thread Raw
In response to Re: Exposing the lock manager's WaitForLockers() to SQL  (Will Mortensen <will@extrahop.com>)
Responses Re: Exposing the lock manager's WaitForLockers() to SQL
List 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 by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Impact of checkpointer during pg_upgrade
Next
From: Amit Kapila
Date:
Subject: Re: pg_upgrade and logical replication