Re: Zeroing damaged pages

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Zeroing damaged pages
Date: 2006-02-23 17:26:08
Message-ID: 1140715568.8759.219.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

On Thu, 2006-02-23 at 11:54 -0500, Tom Lane wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-02-23 18:10:07 Foreign keys for non-default datatypes
Previous Message Stephan Szabo 2006-02-23 17:22:23 Re: Request: set opclass for generated unique and primary

Browse pgsql-patches by date

  From Date Subject
Next Message Jim C. Nasby 2006-02-23 17:59:10 Re: [PATCHES] Summary table trigger example race condition
Previous Message Andrew Dunstan 2006-02-23 17:20:25 fix initdb -U