From b25116ac9734167d95f64146467cf227e760d823 Mon Sep 17 00:00:00 2001 From: Heikki Linnakangas Date: Tue, 12 Dec 2017 00:06:59 +0200 Subject: [PATCH] Disable "cannot make new WAL entries during recovery" check again. The check was introduced by the 8.4 merge, but I had disabled it because we were tripping it. I re-enabled it in commit 1df4698aaa, thinking that the other changes in that commit made it work again, but we're seeing pipeline failures on many filerep-related test suites because of this. So disable it again. We really shouldn't hit that sanity check, but the current plan is to revamp this code greatly before the next release, as we are about to start replacing the GPDB-specific file replication with upstream WAL replication. Chances are that it will start to just work once that work is done, so I'm not going to spend any more time investigating this right now. Analysis by Jacob Champion. --- src/backend/access/transam/xlog.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c index bde6579a8a..abe795908c 100644 --- a/src/backend/access/transam/xlog.c +++ b/src/backend/access/transam/xlog.c @@ -907,9 +907,13 @@ XLogInsert_Internal(RmgrId rmid, uint8 info, XLogRecData *rdata, TransactionId h } } + /* GPDB_84_MERGE_FIXME: This cross-check was added in upstream, but it's failing + * in Startup pass 2. Disable it for now. */ +#if 0 /* cross-check on whether we should be here or not */ if (!XLogInsertAllowed()) elog(ERROR, "cannot make new WAL entries during recovery"); +#endif /* info's high bits are reserved for use by me */ if (info & XLR_INFO_MASK) -- GitLab