From: | PG Doc comments form <noreply(at)postgresql(dot)org> |
---|---|
To: | pgsql-docs(at)lists(dot)postgresql(dot)org |
Cc: | anthony(at)berglas(dot)org |
Subject: | Common case not at all clear |
Date: | 2021-07-28 03:48:04 |
Message-ID: | 162744408450.25751.18322473171054919168@wrigleys.postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2021-07-28 23:46:05 | Re: Another pg_dump using split and gzip for large databases |
Previous Message | Tom Lane | 2021-07-27 17:24:03 | Re: Set-Returning functions in a select list |