| From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: use CREATE DATABASE STRATEGY = FILE_COPY in pg_upgrade |
| Date: | 2024-06-19 13:37:17 |
| Message-ID: | ZnLfDSxSl3Os1VAj@nathan |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Jun 19, 2024 at 09:17:00AM -0400, Robert Haas wrote:
> OK, I have a (probably) stupid question. The comment says:
>
> + * In binary upgrade mode, we can skip this checkpoint because neither of
> + * these problems applies: we don't ever replay the WAL generated during
> + * pg_upgrade, and we don't concurrently modify template0 (not to mention
> + * that trying to take a backup during pg_upgrade is pointless).
>
> But what happens if the system crashes during pg_upgrade? Does this
> patch make things worse than they are today? And should we care?
My understanding is that you basically have to restart the upgrade from
scratch if that happens. I suppose there could be a problem if you try to
use the half-upgraded cluster after a crash, but I imagine you have a good
chance of encountering other problems if you do that, too. So I don't
think we care...
--
nathan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Matthias van de Meent | 2024-06-19 13:38:52 | Re: use CREATE DATABASE STRATEGY = FILE_COPY in pg_upgrade |
| Previous Message | Ashutosh Sharma | 2024-06-19 13:35:36 | Re: Avoid orphaned objects dependencies, take 3 |