Message-ID: <35d3e799d47700dc217b1f211aa0e0d5f4de4e67.camel@cybertec.at>
Subject: Re: Questions about document "Concurrenry control" section
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: iseki zero <admin@iseki.space>, pgsql-general@lists.postgresql.org
Date: Wed, 09 Oct 2024 16:51:16 +0200
In-Reply-To: <7901c7e4-69c6-4bb2-8e9d-ad556d493717@iseki.space>
References: <7901c7e4-69c6-4bb2-8e9d-ad556d493717@iseki.space>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.52.4 (3.52.4-1.fc40) 
MIME-Version: 1.0
Archived-At: <https://www.postgresql.org/message-id/35d3e799d47700dc217b1f211aa0e0d5f4de4e67.camel%40cybertec.at>
Precedence: bulk

On Wed, 2024-10-09 at 18:07 +0800, iseki zero wrote:
> I found it difficult to understanding some paragraph in the document=20
> "Concurrency control" section.
>=20
> =C2=A0> The Repeatable Read mode provides a rigorous guarantee that each=
=20
> transaction sees a completely stable view of the database. However, this=
=20
> view will not necessarily always be consistent with some serial (one at=
=20
> a time) execution of concurrent transactions of the same level. For=20
> example, even a read-only transaction at this level may see a control=20
> record updated to show that a batch has been completed but/not/see one=
=20
> of the detail records which is logically part of the batch because it=20
> read an earlier revision of the control record. Attempts to enforce=20
> business rules by transactions running at this isolation level are not=
=20
> likely to work correctly without careful use of explicit locks to block=
=20
> conflicting transactions.
>=20
> At:=20
> https://www.postgresql.org/docs/17/transaction-iso.html#XACT-REPEATABLE-R=
EAD:~:text=3DThe%20Repeatable%20Read%20mode,to%20block%20conflicting%20tran=
sactions.
>=20
> Specifically, I can't understand the example.

I think this is referring to this example:
https://wiki.postgresql.org/wiki/SSI#Deposit_Report

Yours,
Laurenz Albe