From: Tom Lane <tgl@sss.pgh.pa.us>
To: David G. Johnston <david.g.johnston@gmail.com>
Cc: ZhangChi <798604270@qq.com>
Cc: pgsql-bugs <pgsql-bugs@lists.postgresql.org>
Subject: Re: BUG #19036: Failed prepared INSERT statement make another SELECT query generate wrong result
Date: Fri, 29 Aug 2025 22:06:32 -0400
Message-ID: <2504804.1756519592@sss.pgh.pa.us> (raw)
In-Reply-To: <CAKFQuwZdRbac7ajisTqDSJp7Djj4EQCBJDkNb7de10nYd4gBrQ@mail.gmail.com>
References: <19036-ef3954ff85feefe2@postgresql.org>
<2163312.1756480422@sss.pgh.pa.us>
<tencent_E04DDAE3FA433396407721AEB3E655C81C09@qq.com>
<CAKFQuwZdRbac7ajisTqDSJp7Djj4EQCBJDkNb7de10nYd4gBrQ@mail.gmail.com>
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Friday, August 29, 2025, ZhangChi <798604270@qq.com> wrote:
>> I still have a problem with this. When an INSERT fails, why not undo all
>> the effects of the INSERT?
> Performance.
Yeah. You can certainly argue that it was a design error to make
nextval() nontransactional, but the performance advantages are
compelling. Most critically, if we required that, then any
transaction doing nextval() would block all other transactions from
doing nextval() on the same sequence: they'd have to wait to see if
the first one committed before they could know what value to use.
(Deadlocks between nextval's on different sequences could be a problem
as well.) So the odds that we'd change that are nil, even if there
weren't a few decades worth of backwards compatibility to worry about.
regards, tom lane
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: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, david.g.johnston@gmail.com, 798604270@qq.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #19036: Failed prepared INSERT statement make another SELECT query generate wrong result
In-Reply-To: <2504804.1756519592@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox