From: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Nathan Bossart <nathandbossart(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:38:52 |
Message-ID: | CAEze2WgPd2f=L_9oW_za9CiCpgs=gjy8Wgkdoy_1f0ACeuyNug@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 19 Jun 2024 at 15:17, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Fri, Jun 14, 2024 at 5:29 PM Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
> > On Wed, Jun 12, 2024 at 09:41:01AM -0500, Nathan Bossart wrote:
> > > Actually, I think you are right that we need a manual checkpoint, except I
> > > think we need it to be after prepare_new_globals(). set_frozenxids()
> > > connects to each database (including template0) and updates a bunch of
> > > pg_class rows, and we probably want those on disk before we start copying
> > > the files to create all the user's databases.
> >
> > Here is an updated patch.
>
> 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?
As Nathan just said, AFAIK we don't have a way to resume progress from
a crashed pg_upgrade, which implies you currently have to start over
with a fresh dbinit.
This patch wouldn't change that for the worse, it'd only add one more
process that depends on that behaviour.
Maybe in the future that'll change if pg_upgrade and pg_dump are made
smart enough to resume their restore progress across forceful
disconnects, but for now this patch seems like a nice performance
improvement.
Kind regards,
Matthias van de Meent
Neon (https://neon.tech)
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2024-06-19 13:43:12 | Re: Proposal for Updating CRC32C with AVX-512 Algorithm. |
Previous Message | Nathan Bossart | 2024-06-19 13:37:17 | Re: use CREATE DATABASE STRATEGY = FILE_COPY in pg_upgrade |