teach pg_upgrade to handle in-place tablespaces

(Creating new thread from https://postgr.es/m/Z-MaPREQvH5YB0af%40nathan.)

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.

--
nathan

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