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
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 |
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 |