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 <nathandboss...@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 <br...@momjian.us> https://momjian.us EDB https://enterprisedb.com Do not let urgent matters crowd out time for investment in the future.
