Re: Logical WAL sender unresponsive during decoding commit
От | Amit Kapila |
---|---|
Тема | Re: Logical WAL sender unresponsive during decoding commit |
Дата | |
Msg-id | CAA4eK1+B6qECQi=pURJV6w3wV+ZGS6C78-NiDi5zUhUJpvnaOg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Logical WAL sender unresponsive during decoding commit (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Logical WAL sender unresponsive during decoding commit
|
Список | pgsql-hackers |
On Thu, Oct 20, 2022 at 5:17 AM Robert Haas <robertmhaas@gmail.com> wrote: > > > > Pushed. > > I think this was a good change, but there's at least one other problem > here: within ReorderBufferRestoreChanges, the while (restored < > max_changes_in_memory && *segno <= last_segno) doesn't seem to contain > a CFI. Note that this can loop either by repeatedly failing to open a > file, or by repeatedly reading from a file and passing the data read > to ReorderBufferRestoreChange. So I think there should just be a CFI > at the top of this loop to make sure both cases are covered. > Agreed. The failures due to file operations can make this loop unpredictable in terms of time, so it is a good idea to have CFI at the top of this loop. I can take care of this unless there are any objections or you want to do it. We have backpatched the previous similar change, so I think we should backpatch this as well. What do you think? -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: