From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Kuntal Ghosh <kuntalghosh(dot)2007(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, Amit Kapila <amit(dot)kapila(at)enterprisedb(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com> |
Subject: | Re: WAL consistency check facility |
Date: | 2016-08-23 05:27:39 |
Message-ID: | CAB7nPqQB2hFGXH_TY+oZdNa0p8iWuGnLEH2o23Z2qH8i95-8Xw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Aug 23, 2016 at 1:32 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> On Mon, Aug 22, 2016 at 9:16 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Mon, Aug 22, 2016 at 9:25 AM, Michael Paquier
>> <michael(dot)paquier(at)gmail(dot)com> wrote:
>>> Another pin-point is: given a certain page, how do we identify of
>>> which type it is? One possibility would be again to extend the AM
>>> handler with some kind of is_self function with a prototype like that:
>>> bool handler->is_self(Page);
>>> If the page is of the type of the handler, this returns true, and
>>> false otherwise. Still here performance would suck.
>>>
>>> At the end, what we want is a clean interface, and more thoughts into it.
>>
>> I think that it makes sense to filter based on the resource manager
>> ID
>>
>
> +1.
Yes actually that's better. That's simple enough and removes any need
to looking at pd_special.
> I think the patch currently addresses only a subset of resource
> manager id's (mainly Heap and Index resource manager id's). Do we
> want to handle the complete resource manager list as defined in
> rmgrlist.h?
Not all of them generate FPWs. I don't think it matters much.
> Another thing that needs some thoughts is the UI of this patch,
> currently it is using integer mask which might not be best way, but
> again as it is intended to be mainly used for tests, it might be okay.
What we'd want to have is a way to visualize easily differences of
pages. Any other ideas than MASK_MARKER would be welcome of course.
> Do we want to enable some tests in the regression suite by using this option?
We could get out a recovery test that sets up a standby/master and
runs the tests of src/test/regress with pg_regress with this parameter
enabled.
+ * bufmask.c
+ * Routines for buffer masking, used to ensure that buffers used for
+ * comparison across nodes are in a consistent state.
+ *
+ * Portions Copyright (c) 1996-2014, PostgreSQL Global Development Group
+ * Portions Copyright (c) 1994, Regents of the University of California
Copyright notices need to be updated. (It's already been 2 years!!)
Also, what's the use case of allowing only a certain set of rmgrs to
be checked. Wouldn't a simple on/off switch be simpler? As presented,
wal_consistency_mask is also going to be very quite confusing for
users. You should not need to apply some maths to set up this
parameter, a list of rmgr names may be more adapted if this level of
tuning is needed, still it seems to me that we don't need this much.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | amul sul | 2016-08-23 05:28:37 | Re: Bug in to_timestamp(). |
Previous Message | Kuntal Ghosh | 2016-08-23 05:15:04 | Re: WAL consistency check facility |