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.
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 |