Re: Logical WAL sender unresponsive during decoding commit
От | Robert Haas |
---|---|
Тема | Re: Logical WAL sender unresponsive during decoding commit |
Дата | |
Msg-id | CA+TgmoZ_o_1C3VMOiHe0+HdsXpEPhkcTdLw-Bsv=-uxV9P=vPA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Logical WAL sender unresponsive during decoding commit (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: Logical WAL sender unresponsive during decoding commit
|
Список | pgsql-hackers |
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. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: