On Tue, Aug 30, 2016 at 10:24 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Michael Paquier <michael.paqu...@gmail.com> writes: >> On Tue, Aug 30, 2016 at 9:48 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> Hm, StartupXLOG seems like a pretty random place to check that, especially >>> since doing it there requires an extra stat() call. Why didn't you just >>> make readRecoveryCommandFile() error out? > >> Well, the idea is to do the check before doing anything on PGDATA and >> leave it intact, particularly the post-crash fsync(). > > I don't see anything very exciting between the beginning of StartupXLOG > and readRecoveryCommandFile. In particular, doing the fsync seems like > a perfectly harmless and maybe-good thing. If there were some operation > with potentially bad side-effects in that range, it would be dangerous > anyway because of the risk of readRecoveryCommandFile erroring out due > to invalid contents of recovery.conf.
Does the attached suit better then? -- Michael
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c index acd95aa..5426f75 100644 --- a/src/backend/access/transam/xlog.c +++ b/src/backend/access/transam/xlog.c @@ -4957,6 +4957,16 @@ readRecoveryCommandFile(void) errmsg("could not open recovery command file \"%s\": %m", RECOVERY_COMMAND_FILE))); } + else if (!IsPostmasterEnvironment) + { + /* + * Prevent standalone process to start if recovery is wanted. A lot of + * code paths in recovery depend on the assumption that it is not the + * case so recovery would just badly fail. + */ + ereport(FATAL, + (errmsg("recovery.conf is not allowed in a standalone process"))); + } /* * Since we're asking ParseConfigFp() to report errors as FATAL, there's
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers