Re: Proposal for Recover mode in pg_ctl (in 8.0)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Proposal for Recover mode in pg_ctl (in 8.0)
Date: 2004-11-06 23:29:44
Message-ID: 17718.1099783784@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> If a further pg_ctl mode, recover, were implemented, this would allow a
> fail safe mode for recovery.

> e.g. pg_ctl -D datadir recover

> pg_ctl could then check for the existence of a recovery.conf file and
> return an error if none were found.

I can't get very excited about this approach, because it only protects
those people who (a) use pg_ctl to start the postmaster (not everyone)
and (b) carefully follow the recovery directions (which the people you
are worried about are very bad at, by hypothesis).

A possibly more reliable interlock would involve having the postmaster
probe during normal startup to see if there is already an archived WAL
segment for what it thinks is the current segment. However there are
several issues here: one is that if you're doing partial-log-file
shipping, that isn't necessarily an error condition; another is that
we don't know how to do such a probe unless more information is added
to postgresql.conf. We could imagine adding another shell command
string (something like "test -f ..." perhaps) but if the user gets it
wrong he may still be left with no protection.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mark Kirkwood 2004-11-06 23:46:16 Re: Proposal for Recover mode in pg_ctl (in 8.0)
Previous Message Tom Lane 2004-11-06 23:14:41 Re: Increasing the length of pg_stat_activity.current_query...