Re: Possible G2-item at SERIALIZABLE

From: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
To: Kyle Kingsbury <aphyr(at)aphyr(dot)com>
Cc: PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: Possible G2-item at SERIALIZABLE
Date: 2026-05-31 13:19:55
Message-ID: 84AC98E5-3387-40A5-A258-C6E354349154@yandex-team.ru
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hello Kyle!

> On 22 May 2026, at 21:44, Kyle Kingsbury <aphyr(at)aphyr(dot)com> wrote:
>
> I am relatively confident that isolation levels and transactions are
> being used correctly, because when I adjust the isolation level from
> Serializable to (e.g.) Read Committed, I see vastly different anomalies.
> I can also reproduce the problem both using JDBC's transaction calls,
> and with explicit BEGIN; SET TRANSACTION ISOLATION LEVEL
> SERIALIZABLE; ...; COMMIT;, which makes me think that it's not a bug in
> the way next.jdbc or the JDBC driver handle transactions.

I agree the multi-statement path looks correct, and I don't think next.jdbc or the
driver are at fault either. But I think there's a narrower issue that both of your
checks leave untouched: single-operation transactions are never wrapped in
a transaction at all.

In append's invoke!, a transaction is only opened when it has more than one op [0].

Could you confirm whether you still observe G2-item anomalies with a server
configured default_transaction_isolation = 'serializable' (so that the
single-statement operations are certainly Serializable)? If they persist under that
setting I'll dig further...

Best regards, Andrey Borodin.

[0] https://github.com/jepsen-io/sql/blob/6e34b76e2ac6a1c3edb5a9cab1c835eda4ca4c5e/src/jepsen/sql/append.clj#L155-L160

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Andrey Borodin 2026-05-31 13:33:06 Re: BUG #19458: OOM killer in jsonb_path_exists_opr (@?) with malformed JSONPath containing non-existent variables
Previous Message Heikki Linnakangas 2026-05-31 10:14:43 Re: BUG #19490: Streaming standby on 16.14 stops applying WAL on MultiXactOffsetSLRU when primary is 16.8