Re: Common case not at all clear

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: anthony(at)berglas(dot)org, pgsql-docs(at)lists(dot)postgresql(dot)org
Subject: Re: Common case not at all clear
Date: 2021-07-29 15:14:17
Message-ID: 20210729151417.GH9600@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-docs

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(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com

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

In response to

Browse pgsql-docs by date

  From Date Subject
Next Message David G. Johnston 2021-07-29 15:17:23 Re: Common case not at all clear
Previous Message Bruce Momjian 2021-07-29 14:58:55 Re: Another pg_dump using split and gzip for large databases