Re: teach pg_upgrade to handle in-place tablespaces - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: teach pg_upgrade to handle in-place tablespaces
Date
Msg-id aA_6wKsPgqfbEypy@nathan
Whole thread Raw
In response to teach pg_upgrade to handle in-place tablespaces  (Nathan Bossart <nathandbossart@gmail.com>)
List pgsql-hackers
On Mon, Apr 28, 2025 at 04:07:16PM -0500, Nathan Bossart wrote:
> On Tue, Mar 25, 2025 at 04:03:57PM -0500, Nathan Bossart wrote:
>> I also wanted to draw attention to this note in 0003:
>> 
>>         /*
>>          * XXX: The below line is a hack to deal with the fact that we
>>           * presently don't have an easy way to find the corresponding new
>>           * tablespace's path.  This will need to be fixed if/when we add
>>           * pg_upgrade support for in-place tablespaces.
>>           */
>>          new_tablespace = old_tablespace;
>> 
>> I intend to address this in v19, primarily to enable same-version
>> pg_upgrade testing with non-default tablespaces.  My current thinking is
>> that we should have pg_upgrade also gather the new cluster tablespace
>> information and map them to the corresponding tablespaces on the old
>> cluster.  This might require some refactoring in pg_upgrade.  In any case,
>> I didn't feel this should block the feature for v18.
> 
> Patch attached.

And here is a new version of the patch that should hopefully build on
Windows.

-- 
nathan

Attachment

pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: Large expressions in indexes can't be stored (non-TOASTable)
Next
From: Nathan Bossart
Date:
Subject: Re: Disallow redundant indexes