Re: Use-after-free in reorderbuffer.c for INSERT ON CONFLICT
От | Amit Kapila |
---|---|
Тема | Re: Use-after-free in reorderbuffer.c for INSERT ON CONFLICT |
Дата | |
Msg-id | CAA4eK1JOk2u=co1VHRbxH6D=dXCcxTtJosR2qyvhCiL9qgOXBw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Use-after-free in reorderbuffer.c for INSERT ON CONFLICT (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Use-after-free in reorderbuffer.c for INSERT ON CONFLICT
|
Список | pgsql-bugs |
On Fri, Aug 1, 2025 at 5:15 PM 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. > The proposed change looks good to me. -- With Regards, Amit Kapila.
В списке pgsql-bugs по дате отправления: