Re: [HACKERS] Should buffer of initialization fork have aBM_PERMANENT flag
От | Michael Paquier |
---|---|
Тема | Re: [HACKERS] Should buffer of initialization fork have aBM_PERMANENT flag |
Дата | |
Msg-id | CAB7nPqSeN5m7o2zCNNznMo6_oN4_VD-zoo8HpLMBEtO3RLeQmQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Should buffer of initialization fork have aBM_PERMANENT flag (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [HACKERS] Should buffer of initialization fork have aBM_PERMANENT flag
|
Список | pgsql-hackers |
On Tue, Mar 14, 2017 at 4:46 AM, Robert Haas <robertmhaas@gmail.com> wrote: > On Wed, Jan 25, 2017 at 7:14 PM, Michael Paquier > <michael.paquier@gmail.com> wrote: >> (Adding Robert in CC.) >> >> On Thu, Jan 26, 2017 at 4:34 AM, Wang Hao <whberet@gmail.com> wrote: >>> An unlogged table has an initialization fork. The initialization fork does >>> not have an BM_PERMANENT flag when get a buffer. >>> In checkpoint (not shutdown or end of recovery), it will not write to disk. >>> after a crash recovery, the page of initialization fork will not correctly, >>> then make the main fork not correctly too. >> >> For init forks the flush need absolutely to happen, so that's really >> not good. We ought to fix BufferAlloc() appropriately here. > > I agree with that, but I propose the attached version instead. It > seems cleaner to have the entire test for setting BM_PERMANENT in one > place rather than splitting it up as you did. Fine for me. You may want to update the comment of BM_PERMANENT in buf_internals.h as Artur has mentioned upthread. For example by just adding "and init forks". > I believe this sets a record for the longest-lived data corruption bug > in a commit made by me. Really? I'll need to double-check the git history here. > Six years and change, woohoo. :-( And that much for someone to report it. -- Michael
В списке pgsql-hackers по дате отправления: