teach pg_upgrade to handle in-place tablespaces

Nathan Bossart <nathandbossart@gmail.com>

From: Nathan Bossart <nathandbossart@gmail.com>
To: pgsql-hackers@postgresql.org
Date: 2025-04-28T21:07:16Z
Lists: pgsql-hackers

Attachments

(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

Commits

  1. Teach pg_upgrade to handle in-place tablespaces.