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@gmail.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@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

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