Re: [PoC] pg_upgrade: allow to upgrade publisher node

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Julien Rouhaud <rjuju123(at)gmail(dot)com>
Cc: "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Subject: Re: [PoC] pg_upgrade: allow to upgrade publisher node
Date: 2023-05-02 10:55:18
Message-ID: 20230502105518.77iznnr4lizpyhkt@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2023-Apr-07, Julien Rouhaud wrote:

> That being said, I have a hard time believing that we could actually preserve
> physical replication slots. I don't think that pg_upgrade final state is fully
> reproducible: not all object oids are preserved, and the various pg_restore
> are run in parallel so you're very likely to end up with small physical
> differences that would be incompatible with physical replication. Even if we
> could make it totally reproducible, it would probably be at the cost of making
> pg_upgrade orders of magnitude slower. And since many people are already
> complaining that it's too slow, that doesn't seem like something we would want.

A point on preserving physical replication slots: because we change WAL
format from one major version to the next (adding new messages or
changing format for other messages), we can't currently rely on physical
slots working across different major versions.

So IMO, for now don't bother with physical replication slot
preservation, but do keep the option name as specific to logical slots.

--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2023-05-02 10:57:19 Re: Logging parallel worker draught
Previous Message Dagfinn Ilmari Mannsåker 2023-05-02 10:48:43 Re: Tab completion for CREATE SCHEMAAUTHORIZATION