Re: Hot standby, recovery infra

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Hot standby, recovery infra
Date: 2009-01-31 20:32:43
Message-ID: 4984B56B.4050202@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Simon Riggs wrote:
> On Fri, 2009-01-30 at 13:15 +0200, Heikki Linnakangas wrote:
>> Simon Riggs wrote:
>>> I'm thinking to add a new function that will allow crash testing easier.
>>>
>>> pg_crash_standby() will issue a new xlog record, XLOG_CRASH_STANDBY,
>>> which when replayed will just throw a FATAL error and crash Startup
>>> process. We won't be adding that to the user docs...
>>>
>>> This will allow us to produce tests that crash the server at specific
>>> places, rather than trying to trap those points manually.
>> Heh, talk about a footgun ;-). I don't think including that in CVS is a
>> good idea.
>
> Thought you'd like it. I'd have preferred it in a plugin... :-(
>
> Not really sure why its a problem though. We support
> pg_ctl stop -m immediate, which is the equivalent, yet we don't regard
> that as a footgun.

If you poison your WAL archive with a XLOG_CRASH_RECOVERY record,
recovery will never be able to proceed over that point. There would have
to be a switch to ignore those records, at the very least.

pg_ctl stop -m immediate has some use in a production system, while this
would be a pure development aid. For that purpose, you might as use a
patched version.

Presumably you want to test different kind of crashes and at different
points. FATAL, PANIC, segfault etc. A single crash mechanism like that
will only test one path.

You don't really need to do it with a new WAL record. You could just add
a GUC or recovery.conf option along the lines of recovery_target:
crash_target=0/123456, and check for that in ReadRecord or wherever you
want the crash to occur.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2009-01-31 20:41:26 Re: Hot standby, recovery infra
Previous Message Marko Kreen 2009-01-31 20:32:37 Re: pgevent warnings on mingw