postgres/timescaledb
1
0
Fork 0
mirror of https://github.com/timescale/timescaledb.git synced 2025-05-17 02:53:51 +08:00
Code Issues Packages Projects Releases Wiki Activity

Don't rely on timescaledb.restoring for upgrade

Browse Source 
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
This commit is contained in:
Mats Kindahl 2020-05-04 12:46:01 +02:00 committed by Mats Kindahl
parent 2574e5a563
commit 730822127d
1 changed files with 15 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
src/extension.c
View File

@ -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)