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 | CAA4eK1L8x5CgzShZ2FLW0QLUVqQZxjp9MLpeFbHBqUeN++VEDA@mail.gmail.com обсуждение исходный текст |
Ответ на | 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 Thu, Jul 31, 2025 at 12:14 PM Michael Paquier <michael@paquier.xyz> wrote: > > Ethan Mertz (colleague, in CC) has found a bug in reorderbuffer.c when > processing a REORDER_BUFFER_CHANGE_INTERNAL_SPEC_CONFIRM change, based > on the data gathered from a customer issue. The bug is a > use-after-free, causing random crashes, that can be summarized like > that: ... > > A simple solution suggested by Ethan would be to use the "prev_lsn" > guessed from the change at the beginning of the loop, rather than the > problematic change->lsn. But that does not seem completely right to > me because we can switch to "specinsert" as the change to process, > hence wouldn't we want to call update_progress_txn() based on the LSN > of the actual change we are looking at? > We still won't be able to capture the latest LSN in case of REORDER_BUFFER_CHANGE_INTERNAL_SPEC_ABORT. IIRC, update_progress_txn is used to keep the client active so that when many changes are skipped, the client doesn't timeout. In this case, it seems okay to use prev_lsn as well. -- With Regards, Amit Kapila.
В списке pgsql-bugs по дате отправления: