Re: optimize file transfer in pg_upgrade
| От | Greg Sabino Mullane |
|---|---|
| Тема | Re: optimize file transfer in pg_upgrade |
| Дата | |
| Msg-id | CAKAnmmJhiSkOvQR1eNkW3-jmdz96gbMvO6tjva-9qAO0OzvQ5A@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: optimize file transfer in pg_upgrade (Nathan Bossart <nathandbossart@gmail.com>) |
| Ответы |
Re: optimize file transfer in pg_upgrade
Re: optimize file transfer in pg_upgrade |
| Список | pgsql-hackers |
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.
Cheers,
Greg
--
Crunchy Data - https://www.crunchydata.com
Enterprise Postgres Software Products & Tech Support
В списке pgsql-hackers по дате отправления: