Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51.11.12\))
Subject: Re: Transaction Isolation level for ERP software
From: Christophe Pettus <xof@thebuild.com>
In-Reply-To: 
 <CADWR+qdOYKvq6WCUsB8bs+V_5DL-qX8B_b=EbHiatvOimCfaYg@mail.gmail.com>
Date: Wed, 15 Jul 2026 10:52:57 -0700
Cc: pgsql-general@lists.postgresql.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <D103EAA7-2AC1-460D-9200-AF9C304A66DC@thebuild.com>
References: 
 <CADWR+qdOYKvq6WCUsB8bs+V_5DL-qX8B_b=EbHiatvOimCfaYg@mail.gmail.com>
To: Mihir Kandoi <kandoimihir@gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/D103EAA7-2AC1-460D-9200-AF9C304A66DC%40thebuild.com>
Precedence: bulk


> On Jul 15, 2026, at 10:34, Mihir Kandoi <kandoimihir@gmail.com> wrote:
>     =E2=80=A2 Is READ COMMITTED actually a better solution or should =
we go with retrying transactions?

There's nothing specific about ERP platforms regarding the transaction =
isolation mode, and READ COMMITTED isn't "better" than REPEATABLE READ =
or vice versa.  It's a matter of what semantics you want for =
transactions: do you want a persistent snapshot that does not change (in =
from the perspective of the session with the open transaction) between =
statements, or can your application tolerate that?

In general, you want to use the weakest transaction isolation mode that =
gives you the semantics that you want.  If your application is written =
to expect that the snapshot of the database does not change during the =
course of the transaction, you'll need REPEATABLE READ, and then need to =
come up with a solution for the serialization errors that you receive.

The source of serialization failures in REPEATABLE READ is two sessions =
attempting to update the same rows.  That's probably the issue you =
should consider tracking down, since that has plenty of other potential =
problems (lock waits, deadlocks) apart from REPEATABLE READ.=