Re: [HACKERS] Should buffer of initialization fork have a BM_PERMANENT flag

2017-03-14 Thread Michael Paquier
On Wed, Mar 15, 2017 at 1:13 AM, Robert Haas wrote: > On Mon, Mar 13, 2017 at 8:51 PM, Michael Paquier > wrote: >>> I agree with that, but I propose the attached version instead. It >>> seems cleaner to have the entire test for setting

Re: [HACKERS] Should buffer of initialization fork have a BM_PERMANENT flag

2017-03-14 Thread Robert Haas
On Mon, Mar 13, 2017 at 8:51 PM, Michael Paquier wrote: >> 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

Re: [HACKERS] Should buffer of initialization fork have a BM_PERMANENT flag

2017-03-13 Thread Michael Paquier
On Tue, Mar 14, 2017 at 4:46 AM, Robert Haas wrote: > On Wed, Jan 25, 2017 at 7:14 PM, Michael Paquier > wrote: >> (Adding Robert in CC.) >> >> On Thu, Jan 26, 2017 at 4:34 AM, Wang Hao wrote: >>> An unlogged table has an

Re: [HACKERS] Should buffer of initialization fork have a BM_PERMANENT flag

2017-03-13 Thread Robert Haas
On Wed, Jan 25, 2017 at 7:14 PM, Michael Paquier wrote: > (Adding Robert in CC.) > > On Thu, Jan 26, 2017 at 4:34 AM, Wang Hao wrote: >> An unlogged table has an initialization fork. The initialization fork does >> not have an BM_PERMANENT flag when

Re: [HACKERS] Should buffer of initialization fork have a BM_PERMANENT flag

2017-03-10 Thread Michael Paquier
On Sat, Mar 11, 2017 at 12:03 AM, Artur Zakirov wrote: > Because BM_PERMANENT is used for init forks of unlogged indexes now. Yes, indeed. -- Michael diff --git a/contrib/bloom/blinsert.c b/contrib/bloom/blinsert.c index 913f1f8a51..3557b106d8 100644 ---

Re: [HACKERS] Should buffer of initialization fork have a BM_PERMANENT flag

2017-03-10 Thread Artur Zakirov
On 10.03.2017 04:00, Michael Paquier wrote: On Thu, Mar 9, 2017 at 10:25 PM, Artur Zakirov wrote: I think this is good fixes. I've checked them. And in my opinion they are correct. The code also is good. Having something with conflicts is not nice, so attached is a

Re: [HACKERS] Should buffer of initialization fork have a BM_PERMANENT flag

2017-03-09 Thread Michael Paquier
On Thu, Mar 9, 2017 at 10:25 PM, Artur Zakirov wrote: > I think this is good fixes. I've checked them. And in my opinion they are > correct. > > The code also is good. Having something with conflicts is not nice, so attached is a rebased version. > I have run

Re: [HACKERS] Should buffer of initialization fork have a BM_PERMANENT flag

2017-03-09 Thread Artur Zakirov
Hello, I wanted to review the patch. But the patch is applied with errors. I've rebased the local copy and have done review on it. I'm not sure is it properly to send rebased patch by reviewer, so I haven't sent it to avoid confuses. On 29.01.2017 17:00, Michael Paquier wrote: Attached is

Re: [HACKERS] Should buffer of initialization fork have a BM_PERMANENT flag

2017-01-29 Thread Michael Paquier
On Thu, Jan 26, 2017 at 9:14 AM, Michael Paquier wrote: > So the patch attached fixes the problem by changing BufferAlloc() in > such a way that initialization forks are permanently written to disk, > which is what you are suggesting. As a simple fix for back-branches >

Re: [HACKERS] Should buffer of initialization fork have a BM_PERMANENT flag

2017-01-25 Thread Michael Paquier
(Adding Robert in CC.) On Thu, Jan 26, 2017 at 4:34 AM, Wang Hao 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.

[HACKERS] Should buffer of initialization fork have a BM_PERMANENT flag

2017-01-25 Thread Wang Hao
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