From: Zsolt Parragi <zsolt.parragi@percona.com>
In-Reply-To: <92417390-9753-4F6D-AE30-DA10FFF2A4DA@yandex-team.ru>
References: <165342c0-0c75-461e-b334-b997639ad48d@aphyr.com>
 <1F2F4318-437C-4AE1-8413-F94FBDD5AB68@yandex-team.ru>
 <CAN4CZFOKnrRdHfd_SKcaNT33iV-QvLYyvUnO5aM2nuUipnug6A@mail.gmail.com>
 <92417390-9753-4F6D-AE30-DA10FFF2A4DA@yandex-team.ru>
MIME-Version: 1.0
Date: Tue, 2 Jun 2026 16:03:46 -0700
Message-ID: 
 <CAN4CZFOMmmqbXNJx3PXwpDF4EKp-raeLkH4OmUxHGFWEW0VqqA@mail.gmail.com>
Subject: Re: Possible G2-item at SERIALIZABLE
To: pgsql-bugs@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
 <https://www.postgresql.org/message-id/CAN4CZFOMmmqbXNJx3PXwpDF4EKp-raeLkH4OmUxHGFWEW0VqqA%40mail.gmail.com>
Precedence: bulk

Hello

> AFAIU SSI docs do not describe this case clearly.

I agree on that part.

> Do you think that recovering serialization error with ROLLBACK TO SAVEPOINT is a bug?

It does seem like a bug to me.

s1 reads row 2, writes row 1, commits first
s2 writes row 2, then reads row 1 inside a savepoint which gets rolled back

s1 --> s2  (s1 read row 2 before s2 wrote it)
s2 --> s1  (s2 read row 1 before it saw s1's write)

Serialization is defined over what each transaction observed ("SSI is
based on the observation"), and whether those observations can be
arranged into one consistent order. I think a rolled-back read still
matters because we can't roll back the fact that the transaction
observed state.

Also, if we try to use the rolled back read for something later, like this:

SAVEPOINT s;
SELECT (balance >= 100) AS do_bonus FROM accounts WHERE id = 1 \gset
ROLLBACK TO SAVEPOINT s;
\if :do_bonus
UPDATE accounts SET bonus = bonus + 10 WHERE id = 2;
\endif
COMMIT;

it will abort on master, the questionable behavior only happens if the
read is unused. Based on this, I think even an unused read should
correctly abort for consistency.

I think we can also argue for this based on the point about locking
from README-SSI:

"Because reads in a subtransaction may cause that subtransaction
to roll back, thereby affecting what is written by the top level
transaction, predicate locks must survive a subtransaction rollback."