Greetings,
* Bruce Momjian (bruce@momjian.us) wrote:
> On Thu, Jun 18, 2020 at 01:42:41PM -0400, Stephen Frost wrote:
> > > > > Yeah, we could add a flag to pg_upgrade to
> > > > > allow this if you are not upgrading replicas, but why bother? It might
> > > > > even work if you create the new replicas with the same WAL segment size,
> > > > > but why add complexity for pg_upgrade, which is already complex enough.
> > > >
> > > > Users already have to deal with various options that need to be
> > > > configured to match up between the primary and replicas, so this really
> > > > seems like it's entirely independent of pg_upgrade and isn't something
> > > > pg_upgrade needs to be worrying about..
> > >
> > > Do you know why we require this step?
> > >
> > > https://www.postgresql.org/docs/12/pgupgrade.html
> > >
> > > Also, change wal_level to replica in the postgresql.conf file on
> > > the new primary cluster.
> >
> > Well, we'll need wal_level to be at least replica if we're going to have
> > replicas streaming from the primary..
>
> But how do they have replicas if wal_level = minimum? Also, why not
> higher replication levels? Should we adjust that doc text?
I think the comment is saying that pg_resetwal will rewrite the
pg_control with a WAL level of minimal and that's the issue and why
the server needs to be brought up with a higher WAL level temporarily,
so that pg_control gets updated, for the new cluster.
Of course, before pg_upgrade is run, the old cluster would need to be up
and running with a wal_level higher than minimal in order to have
replicas in the first place, but what we're really talking about here is
the new, upgraded, cluster.
I do think the doc could probably say replica 'or higher'.
Thanks,
Stephen