Re: [Patch] Make pg_checksums skip foreign tablespace directories
Bernd Helmle <mailings@oopsware.de>
From: Bernd Helmle <mailings@oopsware.de>
To: Michael Paquier <michael@paquier.xyz>, Michael Banck <michael.banck@credativ.de>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2020-01-31T10:33:34Z
Lists: pgsql-hackers
Am Freitag, den 31.01.2020, 13:53 +0900 schrieb Michael Paquier: > Indeed, with a bad timing and a crash in the middle of > write_relcache_init_file(), it could be possible to have such a file > left around in the data folder. Having a past tablespace version > left > around after an upgrade is a pilot error in my opinion because > pg_upgrade generates a script to cleanup past tablespaces, no? I'm suprised, why should that be a problem in copy mode? For me this is a fair use case to test upgrades, e.g. for development purposes, if someone want's to still have application tests against the current old version, for fallback and whatever. And people might not want such upgrades as a "fire-and-forget" task. We even have the --clone feature now, making this even faster. If our project policy is to never ever touch an pg_upgrade'd PostgreSQL instance again in copy mode, i wasn't aware of it. And to be honest, even PostgreSQL itself allows you to reuse tablespace locations for multiple instances as well, so the described problem should exist not in upgraded clusters only. Bernd
Commits
-
Skip foreign tablespaces when running pg_checksums/pg_verify_checksums
- 8f9aba1874ec 11.8 landed
- f6e8e8b3809b 12.3 landed
- 428a2609ef64 13.0 landed
-
Add prefix checks in exclude lists for pg_rewind, pg_checksums and base backups
- da2a7180aa0e 11.8 landed
- a8beece956eb 12.3 landed
- bf883b211eae 13.0 landed