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 CAMpnoC5piX2Z9FsXG27+-ZyyYEL6D6rYvn+tvVQkkFLPiE5VHQ@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
Rebased and fixed conflicts.

FWIW re: Andrey's comment in his excellent CF summary email[0]: we're
currently using vanilla Postgres (via Gentoo) on single nodes, and not
anything fancy like Citus. The Citus relationship is just that we were
inspired by Marco's blog post there. We have a variety of clients
written in different languages that generally don't coordinate their
table modifications, and Marco's scheme merely requires them to use
sequences idiomatically, which we can just about manage. :-)

This feature is then a performance optimization to support this scheme
while avoiding the case where one writer holding a RowExclusiveLock
blocks the reader from taking a ShareLock which in turn prevents other
writers from taking a RowExclusiveLock for a long time. Instead, the
reader can wait for the first writer without taking any locks or
blocking later writers. I've illustrated this difference in the
isolation tests.

Still hoping we can get this into 17. :-)

[0] https://www.postgresql.org/message-id/C8D65462-0888-4484-A72C-C99A94381ECD%40yandex-team.ru

Attachment

pgsql-hackers by date:

Previous
From: Yugo NAGATA
Date:
Subject: Re: Remove unnecessary code from psql's watch command
Next
From: Michael Paquier
Date:
Subject: Re: Add comment to specify timeout unit in ConditionVariableTimedSleep()