Date: Tue, 25 Mar 2025 16:03:57 -0500
From: Nathan Bossart <nathandbossart@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>,
	Greg Sabino Mullane <htamfids@gmail.com>,
	pgsql-hackers@postgresql.org, bruce@momjian.us
Subject: Re: optimize file transfer in pg_upgrade
Message-ID: <Z-MaPREQvH5YB0af@nathan>
References: <Z9nEup6k56N_9l0X@nathan>
 <Z9oofphRMQQzgRmL@nathan>
 <Z9rjSmA_MpPz-zOw@nathan>
 <712605.1742401713@sss.pgh.pa.us>
 <can7m7lntp3rpwchr7upnlom4fhzwfwttfa53xks2yxxafxfkv@3nzrihnqmx4g>
 <Z9sbsU4cu7O9glEQ@nathan>
 <Z9s29-mO6wnSEU_r@nathan>
 <Z9t3QsiVz2jHw76A@nathan>
 <Z9w-Qk-ALa__65zs@nathan>
 <Z9x5MVjWO7zVwrJ0@nathan>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Z9x5MVjWO7zVwrJ0@nathan>
Archived-At: <https://www.postgresql.org/message-id/Z-MaPREQvH5YB0af%40nathan>
Precedence: bulk

On Thu, Mar 20, 2025 at 03:23:13PM -0500, Nathan Bossart wrote:
> I'm still aiming to commit this sometime early next week.

Committed.  Thanks to everyone who chimed in on this thread.

While writing the attributions, I noticed that nobody seems to have
commented specifically on 0001.  The closest thing to a review I see is
Greg's note upthread [0].  This patch is a little bigger than what I'd
ordinarily feel comfortable with committing unilaterally, but it's been
posted in its current form since February 28th, this thread has gotten a
decent amount of traffic since then, and it's not a huge change ("9 files
changed, 96 insertions(+), 37 deletions(-)").  I'm happy to address any
post-commit feedback that folks have.  As noted earlier [1], I'm not wild
about how it's implemented, but this is the nicest approach I've thought of
thus far.

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.

[0] https://postgr.es/m/CAKAnmm%2Bi3Q1pZ05N_b8%3DS3B%3DrztQDn--HoW8BRKVtCg53r8NiQ%40mail.gmail.com
[1] https://postgr.es/m/Z9h5Spp76EBygyEL%40nathan

-- 
nathan