Date: Wed, 19 Mar 2025 14:32:01 -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: <Z9sbsU4cu7O9glEQ@nathan>
References: <egjrbbaielccjecm6js5isonhm64zhcqtsoaynbopncreidtes@y3ysztu2d5v4>
 <Z9mtXsBs-31E5ksW@nathan>
 <tlkgkf3woe4ye2l4m4dnwui4wmqtajotozw5r3fhefyuv6hwrl@34xroqbvddpj>
 <Z9mxlf5uVuk2DziP@nathan>
 <7rhxl5nl5cuenm4kzprjhaojo74m2teuwzjffcrdi6bxx6b2wn@orb5h3mteh2y>
 <Z9nEup6k56N_9l0X@nathan>
 <Z9oofphRMQQzgRmL@nathan>
 <Z9rjSmA_MpPz-zOw@nathan>
 <712605.1742401713@sss.pgh.pa.us>
 <can7m7lntp3rpwchr7upnlom4fhzwfwttfa53xks2yxxafxfkv@3nzrihnqmx4g>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <can7m7lntp3rpwchr7upnlom4fhzwfwttfa53xks2yxxafxfkv@3nzrihnqmx4g>
Archived-At: <https://www.postgresql.org/message-id/Z9sbsU4cu7O9glEQ%40nathan>
Precedence: bulk

On Wed, Mar 19, 2025 at 12:44:38PM -0400, Andres Freund wrote:
> On 2025-03-19 12:28:33 -0400, Tom Lane wrote:
>> Nathan Bossart <nathandbossart@gmail.com> writes:
>> > I'm currently planning to commit this sometime early-ish next week.  One
>> > notable loose end is the lack of a pg_upgrade test with a non-default
>> > tablespace, but that is an existing problem that IMHO is best handled
>> > separately (since we can only test it in cross-version upgrades).
>>
>> Agreed that that shouldn't block this, but we need some kind of
>> plan for testing it better.
> 
> Yea, this is really suboptimal.
> 
> Shouldn't allow_in_place_tablespaces be sufficient to deal with that scenario?
> Or at least it should make it reasonably easy to cope if it doesn't already
> suffice?

Unfortunately, pg_upgrade can't yet handle in-place tablespaces.  One
reason is that pg_tablespace_location() returns a relative path for those
(e.g., "pg_tblspc/123456").  We'd also need to adjust init_tablespaces() to
not fail if all the tablespaces are in-place.  There may be other reasons,
too.  I'm confident we could get it working, but I'm not too excited about
trying to sneak this into v18.

In addition to testing with in-place tablespaces, we might also want to
teach the transfer modes test to do cross-version testing when possible.
In that case, we can test normal (non-in-place) tablespaces.  However, that
would be limited to the buildfarm.

Does this seem like a reasonable plan for v19?

-- 
nathan