Re: Unexpected serialization error

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Luka Žitnik <luka(dot)zitnik(at)gmail(dot)com>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: Unexpected serialization error
Date: 2021-02-13 17:21:58
Message-ID: 1661461.1613236918@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

=?UTF-8?B?THVrYSDFvWl0bmlr?= <luka(dot)zitnik(at)gmail(dot)com> writes:
> I had no luck over at general slack channel. So I'm beginning to treat this
> as a bug. Here's a test case that unexpectedly fails at last insert. I
> expect it not to fail because the rows that the two transactions act on are
> unrelated to one another.

The bug is that you're assuming exact tracking of the SSI serialization
rules. It's not done that way, because it'd be prohibitively expensive.
(I've not dug into this example in any detail, but I suspect it's
acquiring page-level not tuple-level predicate locks, thus the
transactions conflict because each tries to update a page the other one
already read.)

The short answer is that ANY application that's depending on serializable
mode MUST be prepared to retry serialization failures. You don't get to
skip that just because there theoretically shouldn't be a failure.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Viktor Semykin 2021-02-13 21:01:31 An issue with missing rows
Previous Message Sven Klemm 2021-02-13 13:59:43 pg_event_trigger_ddl_commands fails with cache lookup failed