From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
---|---|
To: | me(at)jix(dot)one, pgsql-docs(at)lists(dot)postgresql(dot)org |
Subject: | Re: Warn against transaction level advisory locks for emulating "flat file" DBMS locking strategies |
Date: | 2021-09-08 16:26:12 |
Message-ID: | f369dc4469030e51c3afd661a49846cb3e6afcc9.camel@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2021-09-08 16:37:40 | Re: Warn against transaction level advisory locks for emulating "flat file" DBMS locking strategies |
Previous Message | PG Doc comments form | 2021-09-08 08:23:59 | Warn against transaction level advisory locks for emulating "flat file" DBMS locking strategies |