Re: optimize file transfer in pg_upgrade

On Wed, Mar 5, 2025 at 03:40:52PM -0500, Greg Sabino Mullane wrote:
> On Wed, Mar 5, 2025 at 2:43 PM Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
>
> One other design point I wanted to bring up is whether we should bother
> generating a rollback script for the new "swap" mode.  In short, I'm
> wondering if it would be unreasonable to say that, just for this mode, once
> pg_upgrade enters the file transfer step, reverting to the old cluster
> requires restoring a backup.
>
>
> I think that's a fair requirement. And like Robert, revert scripts make me
> nervous.
>
>
> * Anecdotally, I'm not sure I've ever actually seen pg_upgrade fail
> during or after file transfer, and I'm hoping to get some real data about
> that in the near future.  Has anyone else dealt with such a failure?
>
>
> I've seen various failures, but they always get caught quite early. Certainly
> early enough to easily abort, fix perms/mounts/etc., then retry. I think your
> instinct is correct that this reversion is more trouble than its worth. I don't
> think the pg_upgrade docs mention taking a backup, but that's always step 0 in
> my playbook, and that's the rollback plan in the unlikely event of failure.

I avoided many optimizations in pg_upgrade in the fear they would lead
to hard-to-detect bugs, or breakage from major release changes.
pg_upgrade is probably old enough now (15 years) that we can risk these
optimizations.

--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com

Do not let urgent matters crowd out time for investment in the future.