Horton

Re: Use-after-free in reorderbuffer.c for INSERT ON CONFLICT

Masahiko Sawada <sawada.mshk@gmail.com>

View thread
From: Masahiko Sawada <sawada.mshk@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Amit Kapila <amit.kapila16@gmail.com>, Postgres bugs <pgsql-bugs@lists.postgresql.org>, Ethan Mertz <ethan.mertz@gmail.com>
Date: 2025-08-01T16:32:07Z
Lists: pgsql-bugs

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix use-after-free with INSERT ON CONFLICT changes in reorderbuffer.c

On Fri, Aug 1, 2025 at 4:45 AM Michael Paquier <michael@paquier.xyz> wrote:
>
> On Fri, Aug 01, 2025 at 03:30:17PM +0530, Amit Kapila wrote:
> > I mean to say we can use the same change LSN both for
> > REORDER_BUFFER_CHANGE_INTERNAL_SPEC_CONFIRM and
> > REORDER_BUFFER_CHANGE_INTERNAL_SPEC_ABORT. Right now, for
> > REORDER_BUFFER_CHANGE_INTERNAL_SPEC_CONFIRM, we switch the change to
> > specinsert which would have a prior LSN value (say, if confirm/abort
> > record will have value, 1000, it will be 800 or so) but we should
> > still use 1000 for update_progress_txn. The update_progress_txn() is
> > helpful when such an insert is skipped by a plugin (in this case
> > pgouput) and in that case, we would require the latest LSN processed
> > by reorder buffer to pass to it. We use it to send a keep_alive to a
> > client with the last LSN processed.
>
> Ah, OK, I've missed your point then.  It's kind of an optimization in
> itself because we would be a bit more aggressive with the updates, but
> I agree to do that in the scope of this fix.  The updated attached
> uses prev_lsn for the job, for both the ABORT and CONFIRM cases,
> meaning a one-liner.

I assumed that behavior was intentional of the original patch but I'm
fine with the new version patch too if it's not.

Regards,

-- 
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com