Re: prevent immature WAL streaming
От | Amul Sul |
---|---|
Тема | Re: prevent immature WAL streaming |
Дата | |
Msg-id | CAAJ_b97QJH8UNAB=V2NOi-ZidntN5spDnhrU36B_y8yAywEFrg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: prevent immature WAL streaming (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
Ответы |
Re: prevent immature WAL streaming
Re: prevent immature WAL streaming |
Список | pgsql-hackers |
Hi, On Thu, Oct 7, 2021 at 6:57 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote: > > On 2021-Oct-07, Amul Sul wrote: > > > Make sense, thanks for the explanation. > > You're welcome. Also, I forgot: thank you for taking the time to review > the code. Much appreciated. :) > > 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? You might wonder why I am so concerned about the global variable. The reason is that I am working on another thread[1] where we are trying to club all the WAL write operations that happen at the end of StartupXLOG into a separate function. In the future, we might want to allow executing this function from other processes (e.g. Checkpointer). For that, we need to remove the dependency of those WAL write operations having on the global variables which are mostly valid in the startup process. The easiest way to do that is simply copy all the global variables into shared memory but that will not be an optimised solution, the goal is to try to see if we could leverage the existing information available into shared memory. I would be grateful if you could share your thoughts on the same, thanks. Regards, Amul 1] https://postgr.es/m/CAAJ_b97KZzdJsffwRK7w0XU5HnXkcgKgTR69t8cOZztsyXjkQw@mail.gmail.com
Вложения
В списке pgsql-hackers по дате отправления: