Re: prevent immature WAL streaming
От | Amul Sul |
---|---|
Тема | Re: prevent immature WAL streaming |
Дата | |
Msg-id | CAAJ_b97REOc7_-zSWbMtHaUyjGLfpA2p0H8KCBMrK-i1iw3cEg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: prevent immature WAL streaming (Amul Sul <sulamul@gmail.com>) |
Ответы |
Re: prevent immature WAL streaming
|
Список | pgsql-hackers |
On Thu, Oct 14, 2021 at 6:14 PM Amul Sul <sulamul@gmail.com> wrote: > > On Wed, Oct 13, 2021 at 10:58 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote: > > > > On 2021-Oct-13, Amul Sul wrote: > > > > > I have one more question, regarding the need for other global > > > variables i.e. abortedRecPtr. (Sorry for coming back after so long.) > > > > > > Instead of abortedRecPtr point, isn't enough to write > > > overwrite-contrecord at XLogCtl->lastReplayedEndRecPtr? I think both > > > are pointing to the same location then can't we use > > > lastReplayedEndRecPtr instead of abortedRecPtr to write > > > overwrite-contrecord and remove need of extra global variable, like > > > attached? > > > > I'm a bit fuzzy on the difference "the end+1" and "the start of the next > > record". Are they always the same? We do have XLogRecPtrToBytePos() > > and XLogBytePosToEndRecPtr() to convert unadorned XLogRecPtr values to > > "usable byte positions", which suggests to me that the proposed patch > > may fail if end+1 is a page or segment boundary. > > > > Yes, you are correct, that could be a possible failure. > > How about calculating that from the lastReplayedEndRecPtr by > converting it first to "usable byte positions" and then recalculating > the record pointer from that, like attached? > Any thoughts about the patch posted previously? Regards, Amul
В списке pgsql-hackers по дате отправления: