Date: Thu, 29 Jul 2021 11:14:17 -0400
From: Bruce Momjian <bruce@momjian.us>
To: anthony@berglas.org, pgsql-docs@lists.postgresql.org
Subject: Re: Common case not at all clear
Message-ID: <20210729151417.GH9600@momjian.us>
References: <162744408450.25751.18322473171054919168@wrigleys.postgresql.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <162744408450.25751.18322473171054919168@wrigleys.postgresql.org>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: 
 <https://www.postgresql.org/message-id/20210729151417.GH9600%40momjian.us>
Precedence: bulk

On Wed, Jul 28, 2021 at 03:48:04AM +0000, PG Doc comments form 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
> 
> 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.

What documentation text is unclear?

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  If only the physical world exists, free will is an illusion.