Re: BUG #17792: MERGE uses uninitialized pointer and crashes when target tuple is updated concurrently
От | Alvaro Herrera |
---|---|
Тема | Re: BUG #17792: MERGE uses uninitialized pointer and crashes when target tuple is updated concurrently |
Дата | |
Msg-id | 20230215194224.egfyt3j5ewy4c6m3@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: BUG #17792: MERGE uses uninitialized pointer and crashes when target tuple is updated concurrently (Dean Rasheed <dean.a.rasheed@gmail.com>) |
Ответы |
Re: BUG #17792: MERGE uses uninitialized pointer and crashes when target tuple is updated concurrently
|
Список | pgsql-bugs |
On 2023-Feb-15, Dean Rasheed wrote: > On Tue, 14 Feb 2023 at 19:19, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote: > > > > I agree, this looks to be a good fix. However, I couldn't in a quick > > try reproduce the problem, so I haven't been able to verify it. I'll > > try to do that early tomorrow. > > I did some more testing, and the fix looks good. Thank you, I have pushed it. > > (I also delete the XXX comment there.) > > 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. -- Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
В списке pgsql-bugs по дате отправления: