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-03-13 11:46:45 |
Message-ID: | CAEZATCW+NL0Fp3nPnB3eq9UQ_T8iv=rphSssXnWKsyoS5aOwwg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Wed, 15 Feb 2023 at 19:42, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | PG Bug reporting form | 2023-03-13 12:40:11 | BUG #17837: The potential risks associated with executing "commit" in a procedure. |
Previous Message | Arne Roland | 2023-03-13 11:43:09 | Re: Invalid memory allocation error with pg_recvlogical or with libPQ logical connection |