public inbox for [email protected]  
help / color / mirror / Atom feed
From: Zsolt Parragi <[email protected]>
To: [email protected]
Subject: Re: Possible G2-item at SERIALIZABLE
Date: Tue, 2 Jun 2026 16:03:46 -0700
Message-ID: <CAN4CZFOMmmqbXNJx3PXwpDF4EKp-raeLkH4OmUxHGFWEW0VqqA@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<CAN4CZFOKnrRdHfd_SKcaNT33iV-QvLYyvUnO5aM2nuUipnug6A@mail.gmail.com>
	<[email protected]>

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






view thread (10+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected]
  Subject: Re: Possible G2-item at SERIALIZABLE
  In-Reply-To: <CAN4CZFOMmmqbXNJx3PXwpDF4EKp-raeLkH4OmUxHGFWEW0VqqA@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox