From: | David Steele <david(at)pgmasters(dot)net> |
---|---|
To: | Michael Banck <michael(dot)banck(at)credativ(dot)de>, Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [Patch] Make pg_checksums skip foreign tablespace directories |
Date: | 2020-02-19 18:42:53 |
Message-ID: | d294bda7-350b-8411-a6d0-31322176b8c8@pgmasters.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 1/31/20 3:59 AM, Michael Banck wrote:
> Hi,
>
> Am Freitag, den 31.01.2020, 13:53 +0900 schrieb Michael Paquier:
>> On Thu, Jan 30, 2020 at 06:11:22PM +0100, Michael Banck wrote:
>> 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? So
>> your patch does not look like a good idea to me.
>
> Not sure I agree with it, but if that (i.e. after pg_upgrade in copy
> mode, you have no business to use the old cluster as well as the new
> one) is project policy, fair enough.
I don't see how this is project policy. The directories for other
versions of Postgres should be ignored as they are in other utilities,
e.g. pg_basebackup.
> However, Postgres does not disallow to just create tablespaces in the
> same location from two different versions, so you don't need the
> pg_upgade scenario to get into this (pg_checksums checking the wrong
> cluster's data) problem:
Exactly.
Regards,
--
-David
david(at)pgmasters(dot)net
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2020-02-19 19:16:12 | Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index. |
Previous Message | David Steele | 2020-02-19 18:37:00 | Re: [Patch] Make pg_checksums skip foreign tablespace directories |