Re: Protecting against unexpected zero-pages: proposal - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Protecting against unexpected zero-pages: proposal
Date
Msg-id 23601.1289322913@sss.pgh.pa.us
Whole thread Raw
In response to Re: Protecting against unexpected zero-pages: proposal  (Gurjeet Singh <singh.gurjeet@gmail.com>)
Responses Re: Protecting against unexpected zero-pages: proposal
List pgsql-hackers
Gurjeet Singh <singh.gurjeet@gmail.com> writes:
> On Tue, Nov 9, 2010 at 12:32 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> IMO there are a lot of methods that can separate filesystem misfeasance
>> from Postgres errors, probably with greater reliability than this hack.

> Doing this postmortem on a regular deployment and fixing the problem would
> not be too difficult. But this platform, which Postgres is a part of,  would
> be mostly left unattended once deployed (pardon me for not sharing the
> details, as I am not sure if I can).

> An external HA component is supposed to detect any problems (by querying
> Postgres or by external means) and take an evasive action. It is this
> automation of problem detection that we are seeking.

To be blunt, this argument is utter nonsense.  The changes you propose
would still require manual analysis of any detected issues in order to
do anything useful about them.  Once you know that there is, or isn't,
a filesystem-level error involved, what are you going to do next?
You're going to go try to debug the component you know is at fault,
that's what.  And that problem is still AI-complete.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "David E. Wheeler"
Date:
Subject: Re: proposal: plpgsql - iteration over fields of rec or row variable
Next
From: Dmitriy Igrishin
Date:
Subject: Re: proposal: plpgsql - iteration over fields of rec or row variable