Message-ID: <f369dc4469030e51c3afd661a49846cb3e6afcc9.camel@cybertec.at>
Subject: Re: Warn against transaction level advisory locks for emulating
 "flat file" DBMS locking strategies
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: me@jix.one, pgsql-docs@lists.postgresql.org
Date: Wed, 08 Sep 2021 18:26:12 +0200
In-Reply-To: <163108943900.696.7027791431029866787@wrigleys.postgresql.org>
References: <163108943900.696.7027791431029866787@wrigleys.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.40.4 (3.40.4-1.fc34) 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/f369dc4469030e51c3afd661a49846cb3e6afcc9.camel%40cybertec.at>
Precedence: bulk

On Wed, 2021-09-08 at 08:23 +0000, PG Doc comments form wrote:
> The following documentation comment has been logged on the website:
> 
> Page: https://www.postgresql.org/docs/13/explicit-locking.html
> Description:
> 
> The docs mention "For example, a common use of advisory locks is to emulate
> pessimistic locking strategies typical of so-called “flat file” data
> management systems" which is exactly what I wanted to use to port some code
> from using SQLite to using PostgreSQL. (The code in question requires
> serializable transactions and cannot not handle retries.)
> 
> The next paragraph explains session and transaction level advisory locks and
> mentions that transaction level locks are "often more convenient than the
> session-level behavior". This seemed to be true for this use case, so I
> chose to use them.
> 
> Later I discovered that obtaining a transaction level lock as first
> statement _within_ a transaction is not sufficient to emulate global
> pessimistic locking and can occasionally still result in serialization
> failures.

I don't see how that is related to session-level vs. transaction level locks.

erhaps you can explain your case in some more detail.

Yours,
Laurenz Albe
-- 
Cybertec | https://www.cybertec-postgresql.com