Re: Logical WAL sender unresponsive during decoding commit
От | Amit Kapila |
---|---|
Тема | Re: Logical WAL sender unresponsive during decoding commit |
Дата | |
Msg-id | CAA4eK1JtYc4g_+AAba4=WMJ0nw5pDg=6X82ECJe84gHXv1GxJw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Logical WAL sender unresponsive during decoding commit (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
On Thu, Oct 20, 2022 at 7:17 PM Robert Haas <robertmhaas@gmail.com> wrote: > > On Thu, Oct 20, 2022 at 1:37 AM Amit Kapila <amit.kapila16@gmail.com> wrote: > > 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? > > Please go ahead. +1 for back-patching. > Yesterday, I have pushed this change. -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: