Re: BUG #17792: MERGE uses uninitialized pointer and crashes when target tuple is updated concurrently

From: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: exclusion(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #17792: MERGE uses uninitialized pointer and crashes when target tuple is updated concurrently
Date: 2023-02-15 09:41:13
Message-ID: CAEZATCWTFjn6rCx3=NCQhVaRZyi-w=jj8OEmJx9Fb_em5dh4Ew@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Tue, 14 Feb 2023 at 19:19, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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.

> (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.

Regards,
Dean

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Robins Tharakan 2023-02-15 11:16:50 Re: BUG #17791: Assert on procarray.c
Previous Message Kyotaro Horiguchi 2023-02-15 07:12:54 Re: BUG #17789: process_pgfdw_appname() fails for autovacuum workers