Re: BUG #19036: Failed prepared INSERT statement make another SELECT query generate wrong result
От | Tom Lane |
---|---|
Тема | Re: BUG #19036: Failed prepared INSERT statement make another SELECT query generate wrong result |
Дата | |
Msg-id | 2504804.1756519592@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #19036: Failed prepared INSERT statement make another SELECT query generate wrong result ("David G. Johnston" <david.g.johnston@gmail.com>) |
Ответы |
Re: BUG #19036: Failed prepared INSERT statement make another SELECT query generate wrong result
|
Список | pgsql-bugs |
"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
В списке pgsql-bugs по дате отправления: