Re: [PoC] pg_upgrade: allow to upgrade publisher node
От | Julien Rouhaud |
---|---|
Тема | Re: [PoC] pg_upgrade: allow to upgrade publisher node |
Дата | |
Msg-id | 20230502114353.2pnt2lktdaefndnx@jrouhaud обсуждение исходный текст |
Ответ на | Re: [PoC] pg_upgrade: allow to upgrade publisher node (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
Ответы |
Re: [PoC] pg_upgrade: allow to upgrade publisher node
Re: [PoC] pg_upgrade: allow to upgrade publisher node |
Список | pgsql-hackers |
Hi, On Tue, May 02, 2023 at 12:55:18PM +0200, Alvaro Herrera wrote: > 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. I don't think anyone suggested to do physical replication over different major versions. My understanding was that it would be used to pg_upgrade a "physical cluster" (e.g. a primary and physical standby server) at the same time, and then simply starting them up again would lead to a working physical replication on the new version. I guess one could try to keep using the slots for other needs (PITR backup with pg_receivewal or something similar), and then you would indeed have to be aware that you won't be able to do anything with the new WAL records until you do a fresh base backup, but that's a problem that you can already face after a normal pg_upgrade (although in most cases it's probably quite obvious for now as the timeline isn't preserved).
В списке pgsql-hackers по дате отправления: