Можно во всех клиентах использовать advisory locks.

postmanМне действительно надо блокировать доступ на чтение, чтобы одна запись обрабатывалась только ОДНИМ клиентом. Доку читал, тоже ничего кроме экслюзив лока не нашел(может плохо искал)

http://www.sbin.org/doc/pg/doc/explicit-locking.html#ADVISORY-LOCKS

PostgreSQL provides a means for creating locks that have application-defined meanings. These are called advisory locks, because the system does not enforce their use — it is up to the application to use them correctly. Advisory locks can be useful for locking strategies that are an awkward fit for the MVCC model. Once acquired, an advisory lock is held until explicitly released or the session ends. Unlike standard locks, advisory locks do not honor transaction semantics: a lock acquired during a transaction that is later rolled back will still be held following the rollback, and likewise an unlock is effective even if the calling transaction fails later. The same lock can be acquired multiple times by its owning process: for each lock request there must be a corresponding unlock request before the lock is actually released. (If a session already holds a given lock, additional requests will always succeed, even if other sessions are awaiting the lock.) Like all locks in PostgreSQL, a complete list of advisory locks currently held by any session can be found in the pg_locks system view.

Advisory locks are allocated out of a shared memory pool whose size is defined by the configuration variables max_locks_per_transaction and max_connections. Care must be taken not to exhaust this memory or the server will not be able to grant any locks at all. This imposes an upper limit on the number of advisory locks grantable by the server, typically in the tens to hundreds of thousands depending on how the server is configured.

A common use of advisory locks is to emulate pessimistic locking strategies typical of so called "flat file" data management systems. While a flag stored in a table could be used for the same purpose, advisory locks are faster, avoid MVCC bloat, and are automatically cleaned up by the server at the end of the session.


И так далее.

assa
2 Nick Gazaloff кстати, сравнивая доку, вижу, что 12.3.4. Advisory Locks появилось начиная с 8.2. не подскажете - ф-ии в ей сишные?

Не понял. Функции вызываются, как любые другие:

assa Nick Gazaloffпоявилось начиная с 8.2. не подскажете - ф-ии в ей сишные?
Не понял. Функции вызываются, как любые другие:
я не спрашивал, как они вызываются.
судя по идеологии их можно реализовать хоть на plpgsql (+ доп таблички). Однако - наверное это медленнее, чем класть признаки прям в память. А скачивать 8.2 на предмет посмотреть содержимое pg_proc - мне как-то... да, лениво. Вот и спросил вас. Извините, если что.[/quot]

Реализованы они на C, и работают с менеджером блокировок Postgres. То есть, это тоже локи, которые видно в pg_locks. Только смысл их приложение определяет само, и, так как они advisory, то блокируют они только тех, кто их "уважает" (то есть, все клиенты должны обращаться к ним).

Поскольку ими управляет менеджер блокировок Postgres, то они очень быстрые и автоматичиски освобождаются при закрытии сеанса.