On Mon, Jul 18, 2011 at 3:14 AM, Simon Riggs
<simon@2ndquadrant.com> wrote:
On Mon, Jul 18, 2011 at 2:20 AM, Robert Haas <
robertmhaas@gmail.com> wrote:
> On Fri, Jul 15, 2011 at 7:23 AM, Simon Riggs <
simon@2ndquadrant.com> wrote:
>> My additional requests would be that we can easily tell which blocks
>> have been modified like this, that we have a way to turn this off if
>> we get bugs for next few releases, that we check it all works with Hot
>> Standby just fine and that all the block inspection tools support it.
>
> To me, this seems like a bit too much of an internal change to justify
> adding a GUC.
bugs.... getting this wrong is a data loss issue.
Though I understand the fear for data loss, do we have much precedent of adding GUC to control such mechanism ? Even for complex feature like HOT we did not add any GUC to turn it off and I don't think we missed it. So I would suggest we review the code and test the feature extensively and fix the bugs if any, but lets not add any GUC to turn it off. In fact, the code and algorithm itself is not that complex and I would suggest you to take a look at the patch.
> But it probably is a good idea to ping the authors of
> the various block inspection tools -- does contrib/pageinspect care
> about this sort of thing, or just the out-of-core stuff?
I'm the author of the main sections of the pageinspect module, and
yes, I care. :-)
Yeah, we should probably teach pageinspect to see and report this additional information.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB
http://www.enterprisedb.com