Re: use CREATE DATABASE STRATEGY = FILE_COPY in pg_upgrade

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Nathan Bossart <nathandbossart(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:17:00
Message-ID: CA+TgmoZFVVQWv1kn+OuV9NBhLY0McRtuXR3BpWbc=LmR=QuYvA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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?

--
Robert Haas
EDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Aleksander Alekseev 2024-06-19 13:22:21 Re: Add 64-bit XIDs into PostgreSQL 15
Previous Message Matthias van de Meent 2024-06-19 13:07:42 Re: use CREATE DATABASE STRATEGY = FILE_COPY in pg_upgrade