From: | Greg Sabino Mullane <htamfids(at)gmail(dot)com> |
---|---|
To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: optimize file transfer in pg_upgrade |
Date: | 2025-03-05 20:40:52 |
Message-ID: | CAKAnmmJhiSkOvQR1eNkW3-jmdz96gbMvO6tjva-9qAO0OzvQ5A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
Cheers,
Greg
--
Crunchy Data - https://www.crunchydata.com
Enterprise Postgres Software Products & Tech Support
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2025-03-05 21:00:21 | Re: making EXPLAIN extensible |
Previous Message | Robert Haas | 2025-03-05 20:40:18 | Re: Orphaned users in PG16 and above can only be managed by Superusers |