From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Peter Geoghegan <pg(at)heroku(dot)com> |
Cc: | Kuntal Ghosh <kuntalghosh(dot)2007(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Amit Kapila <amit(dot)kapila(at)enterprisedb(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Subject: | Re: WAL consistency check facility |
Date: | 2016-08-28 04:47:28 |
Message-ID: | CAA4eK1JhDSVtkHGPjqy8bwOxzZTRfer58NC3QksxsBw6_hp1vA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Aug 28, 2016 at 6:26 AM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
> On Thu, Aug 25, 2016 at 9:41 AM, Kuntal Ghosh
> <kuntalghosh(dot)2007(at)gmail(dot)com> wrote:
>> 2. For Btree pages, I've masked BTP_HALF_DEAD, BTP_SPLIT_END,
>> BTP_HAS_GARBAGE and BTP_INCOMPLETE_SPLIT flags.
>
> Why? I think that you should only perform this kind of masking where
> it's clearly strictly necessary.
>
> It is true that nbtree can allow cases where LP_DEAD is set with only
> a share lock (by read-only queries), so I can see why BTP_HAS_GARBAGE
> might need to be excluded; this is comparable to the heapam's use of
> hint bits. However, it is unclear why you need to mask the remaining
> btpo_flags that you list, because the other flags have clear-cut roles
> in various atomic operations that we WAL-log.
>
Right, I think there is no need to mask all the flags. However apart
from BTP_HAS_GARBAGE, it seems we should mask BTP_SPLIT_END as that is
just used to save some processing for vaccum and won't be set after
crash recovery or on standby after WAL replay.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2016-08-28 05:50:16 | Re: WAL consistency check facility |
Previous Message | Andres Freund | 2016-08-28 03:38:04 | Re: Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling) |