Re: Protecting against unexpected zero-pages: proposal

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Protecting against unexpected zero-pages: proposal
Дата
Msg-id 23601.1289322913@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Protecting against unexpected zero-pages: proposal  (Gurjeet Singh <singh.gurjeet@gmail.com>)
Ответы Re: Protecting against unexpected zero-pages: proposal  (Gurjeet Singh <singh.gurjeet@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: "David E. Wheeler"
Дата:
Сообщение: Re: proposal: plpgsql - iteration over fields of rec or row variable
Следующее
От: Dmitriy Igrishin
Дата:
Сообщение: Re: proposal: plpgsql - iteration over fields of rec or row variable