Re: Zeroing damaged pages - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Zeroing damaged pages
Date
Msg-id 1140715568.8759.219.camel@localhost.localdomain
Whole thread Raw
In response to Re: Zeroing damaged pages  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Zeroing damaged pages
List pgsql-hackers
On Thu, 2006-02-23 at 11:54 -0500, Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.com> writes:
> > A patch prototype to make zero_damaged_pages work as advertised is
> > enclosed, though the current behaviour may well be preferred, in which
> > case a doc patch is more appropriate. 
> 
> I don't think this is a good idea, and even if it were, the proposed
> patch is a model of obscurantism.

;-)

Just some reflections on a recent db recovery for a client.

> > However, since autovacuum the window of opportunity for support to
> > assist with data recovery is smaller and somewhat random.
> 
> Hmm .... it'd probably be a good idea to force zero_damaged_pages OFF in
> the autovac subprocess.  That parameter is only intended for interactive
> use --- as you say, autovac would be a rather nasty loose cannon if it
> fired up with this parameter ON.

We can:
- disable zero_damaged_pages in autovac
- update the docs to say don't set this in postgresql.conf

> Are there any other things that ought to be disabled in autovac?

Good question. Not AFAICS.

Best Regards, Simon Riggs



pgsql-hackers by date:

Previous
From: Markus Schaber
Date:
Subject: Re: [PERFORM] Looking for a tool to "*" pg tables as ERDs
Next
From: Stephan Szabo
Date:
Subject: Re: Request: set opclass for generated unique and primary