From 730822127d3acda1319918f75d55965528b147f0 Mon Sep 17 00:00:00 2001 From: Mats Kindahl Date: Mon, 4 May 2020 12:46:01 +0200 Subject: [PATCH] Don't rely on timescaledb.restoring for upgrade If a binary upgrade is in progress (when using `pg_upgrade`) the per-database setting of `timescaledb.restoring` can be included in the dump, which causes `pg_upgrade` to fail. This commit fixes this by checking the global variable `IsBinaryUpgrade` and not refreshing cache if we are in the middle of doing a binary upgrade. Fixes #1844 --- src/extension.c | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/src/extension.c b/src/extension.c index f4313156b..b9589b153 100644 --- a/src/extension.c +++ b/src/extension.c @@ -251,8 +251,21 @@ ts_extension_invalidate(Oid relid) bool ts_extension_is_loaded(void) { - /* when restoring deactivate extension */ - if (ts_guc_restoring) + elog(DEBUG1, + "%s: timescaledb.restoring=%s, IsBinaryUpgrade=%s", + __func__, + ts_guc_restoring ? "on" : "off", + IsBinaryUpgrade ? "yes" : "no"); + + /* When restoring deactivate extension. + * + * We are using IsBinaryUpgrade (and ts_guc_restoring). If a user set + * `ts_guc_restoring` for a database, it will be stored in + * `pg_db_role_settings` and be included in a dump, which will cause + * `pg_upgrade` to fail. + * + * See dumpDatabaseConfig in pg_dump.c. */ + if (ts_guc_restoring || IsBinaryUpgrade) return false; if (EXTENSION_STATE_UNKNOWN == extstate || EXTENSION_STATE_TRANSITIONING == extstate)