Feedback-ID: ia2694551:Fastmail
Date: Wed, 15 Feb 2023 20:42:24 +0100
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Dean Rasheed <dean.a.rasheed@gmail.com>
Cc: exclusion@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17792: MERGE uses uninitialized pointer and crashes when
 target tuple is updated concurrently
Message-ID: <20230215194224.egfyt3j5ewy4c6m3@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CAEZATCWTFjn6rCx3=NCQhVaRZyi-w=jj8OEmJx9Fb_em5dh4Ew@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/20230215194224.egfyt3j5ewy4c6m3%40alvherre.pgsql>
Precedence: bulk

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/