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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
