Re: Common case not at all clear - Mailing list pgsql-docs

From David G. Johnston
Subject Re: Common case not at all clear
Date
Msg-id CAKFQuwbjZHASG6uaqRhccMvNsLSHkinjPUTH0m9egCpxwvCYsA@mail.gmail.com
Whole thread Raw
In response to Common case not at all clear  (PG Doc comments form <noreply@postgresql.org>)
Responses Re: Common case not at all clear  (Anthony Berglas <anthony@berglas.org>)
List pgsql-docs
On Thu, Jul 29, 2021 at 8:04 AM PG Doc comments form <noreply@postgresql.org> wrote:
The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/13/transaction-iso.html
Description:

For all this documentation, it is completely unclear how to handle the most
common, simple case.  I.e.

Select balance into :bal  ...where key =123;
Update set balance = :bal+100 where key = 100

That isn't SQL, or any syntax that PostgreSQL supports that I know of.
 
The discussion of read committed for Updates is misleading, I am pretty sure
it will fail if the select is in a different statement, a common case.

I don't believe it is possible for it to fail - or serializable is going to actually result in errors.

Is that how PostgreSql works?  Is that the generally recommended pattern?
Impossible to tell from the docs as written.

That part of the issue with the documentation, they tend to simply say how things work and let the user decide.  Recommendations are uncommon.
 
MVCC really relies on Select
For Update to work for transactions, I think.

IIUC it is basically the difference between optimistic and pessimistic concurrency.  You get to choose which cost/benefit package you want.

My impression is that if you are getting that deep into the bowels of concurrency you should learn and use the serializable isolation level to ensure a consistent linear flow without having to really deal with manual locking directly.

David J.

pgsql-docs by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Common case not at all clear
Next
From: Daniel Gustafsson
Date:
Subject: Re: Another pg_dump using split and gzip for large databases