Re: BUG #17792: MERGE uses uninitialized pointer and crashes when target tuple is updated concurrently
| От | Dean Rasheed |
|---|---|
| Тема | Re: BUG #17792: MERGE uses uninitialized pointer and crashes when target tuple is updated concurrently |
| Дата | |
| Msg-id | CAEZATCW+NL0Fp3nPnB3eq9UQ_T8iv=rphSssXnWKsyoS5aOwwg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: BUG #17792: MERGE uses uninitialized pointer and crashes when target tuple is updated concurrently (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
| Список | pgsql-bugs |
On Wed, 15 Feb 2023 at 19:42, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote: > > On 2023-Feb-15, Dean Rasheed wrote: > > > That makes sense. It's a bit inconsistent (though not related to this > > bug) that a cross-partition update will return OK if the tuple was > > concurrently deleted, so merge will think that it updated the tuple > > and not try an insert action, whereas for a normal update it will try > > an insert action if the tuple was concurrently deleted. The thing that > > seems wrong there is that ExecUpdateAct() sets updateCxt->updated = > > true for a cross-partition update regardless of whether it actually > > executed the insert half of the update/move. In theory, that flag > > could be set to false so that merge would know if the tuple was > > concurrently deleted, though it's not clear if it's worth it. > > Hmm. I wonder if this is just an inconsistency, or rather an outright > bug. > I just pushed a fix for bug #17809 that also fixes this. As part of that, I greatly expanded the isolation tests, to try to cover a lot more of these kinds of cases. Regards, Dean
В списке pgsql-bugs по дате отправления: