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

From PG Doc comments form
Subject Common case not at all clear
Date
Msg-id 162744408450.25751.18322473171054919168@wrigleys.postgresql.org
Whole thread Raw
Responses Re: Common case not at all clear  (Bruce Momjian <bruce@momjian.us>)
Re: Common case not at all clear  ("David G. Johnston" <david.g.johnston@gmail.com>)
Re: Common case not at all clear  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-docs
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

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.

For Oracle, I think that by default a Select will return values at the
beginning of a transaction, Select For Update will return the read committed
value, and Select For Update will wait until conflicting transactions
complete.  So the answer is that the first Select would be a Select For
Update, which should be the normal pattern to be safe (with primary key
access) and minimize deadlocks.

Is that how PostgreSql works?  Is that the generally recommended pattern?
Impossible to tell from the docs as written.  MVCC really relies on Select
For Update to work for transactions, I think.

pgsql-docs by date:

Previous
From: Tom Lane
Date:
Subject: Re: Set-Returning functions in a select list
Next
From: Bruce Momjian
Date:
Subject: Re: Another pg_dump using split and gzip for large databases