Re: Proposal for Recover mode in pg_ctl (in 8.0)
От | Tom Lane |
---|---|
Тема | Re: Proposal for Recover mode in pg_ctl (in 8.0) |
Дата | |
Msg-id | 17718.1099783784@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Proposal for Recover mode in pg_ctl (in 8.0) (Simon Riggs <simon@2ndquadrant.com>) |
Ответы |
Re: Proposal for Recover mode in pg_ctl (in 8.0)
Re: Proposal for Recover mode in pg_ctl (in 8.0) Re: Proposal for Recover mode in pg_ctl (in 8.0) |
Список | pgsql-hackers |
Simon Riggs <simon@2ndquadrant.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
В списке pgsql-hackers по дате отправления: