Re: [Patch] Make pg_checksums skip foreign tablespace directories

From: Bernd Helmle <mailings(at)oopsware(dot)de>
To: Michael Paquier <michael(at)paquier(dot)xyz>, Michael Banck <michael(dot)banck(at)credativ(dot)de>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [Patch] Make pg_checksums skip foreign tablespace directories
Date: 2020-01-31 10:33:34
Message-ID: dd5ef0c1a1bc8f9caee492caf45e1f59c378405d.camel@oopsware.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mark Charsley 2020-01-31 10:47:24 Re: Data race in interfaces/libpq/fe-exec.c
Previous Message Julien Rouhaud 2020-01-31 10:25:07 Re: unsupportable composite type partition keys