Re: Common case not at all clear

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: anthony(at)berglas(dot)org, Pg Docs <pgsql-docs(at)lists(dot)postgresql(dot)org>
Subject: Re: Common case not at all clear
Date: 2021-07-29 15:17:23
Message-ID: CAKFQuwbjZHASG6uaqRhccMvNsLSHkinjPUTH0m9egCpxwvCYsA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-docs

On Thu, Jul 29, 2021 at 8:04 AM PG Doc comments form <noreply(at)postgresql(dot)org>
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
>

That isn't SQL, or any syntax that PostgreSQL supports that I know of.

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

I don't believe it is possible for it to fail - or serializable is going to
actually result in errors.

Is that how PostgreSql works? Is that the generally recommended pattern?
> Impossible to tell from the docs as written.

That part of the issue with the documentation, they tend to simply say how
things work and let the user decide. Recommendations are uncommon.

> MVCC really relies on Select
> For Update to work for transactions, I think.
>

IIUC it is basically the difference between optimistic and pessimistic
concurrency. You get to choose which cost/benefit package you want.

My impression is that if you are getting that deep into the bowels of
concurrency you should learn and use the serializable isolation level to
ensure a consistent linear flow without having to really deal with manual
locking directly.

David J.

In response to

Responses

Browse pgsql-docs by date

  From Date Subject
Next Message Daniel Gustafsson 2021-07-29 15:23:20 Re: Another pg_dump using split and gzip for large databases
Previous Message Bruce Momjian 2021-07-29 15:14:17 Re: Common case not at all clear