suppress automatic recovery after back crash

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: suppress automatic recovery after back crash
Date: 2010-06-28 00:54:40
Message-ID: AANLkTimBAyRSTfiQZMUpCHiwkunv7yK1i8JGv3DJHcK8@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

[moving from -performance to -hackers; original subject is: PostgreSQL
as a local in-memory cache]

On Thu, Jun 17, 2010 at 7:25 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Josh Berkus <josh(at)agliodbs(dot)com> writes:
>>> (a) and (d) are probably simple, if by "reprovisioning" you mean
>>> "rm -rf $PGDATA; initdb".
>
>> Exactly.  Followed by "scp database_image".  Or heck, just replacing the
>> whole VM.
>
> Right, that would work.  I don't think you really need to implement that
> inside Postgres.  I would envision having the startup script do it, ie
>
>        rm -rf $PGDATA
>        cp -pr prepared-database-image $PGDATA
>
>        # this loop exits when postmaster exits normally
>        while ! postmaster ...
>        do
>                rm -rf $PGDATA
>                cp -pr prepared-database-image $PGDATA
>        done
>
> Then all you need is a tweak to make the postmaster exit(1) after
> a crash instead of trying to launch recovery.

This seems useful to me so here's a patch to implement it.

There didn't seem to be a suitable GUC category for it, until I
noticed that we have a currently-undocumented GUC called
exit_on_error. I thought it might make sense to document both that
and this in a new section called "Error Handling".

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

Attachment Content-Type Size
guc_automatic_restart.patch application/octet-stream 6.6 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-06-28 00:55:52 Re: pg_dump's checkSeek() seems inadequate
Previous Message Robert Haas 2010-06-28 00:42:43 Re: pg_dump's checkSeek() seems inadequate