Greetings,
* Bruce Momjian (bruce@momjian.us) wrote:
> On Thu, Jun 18, 2020 at 11:55:37AM -0400, Stephen Frost wrote:
> > * Bruce Momjian (bruce@momjian.us) wrote:
> > > On Thu, Jun 18, 2020 at 11:41:53AM -0400, Stephen Frost wrote:
> > > > Sure, most options to initdb need to be the same between the old cluster
> > > > and the new cluster, but this specific option doesn't have to be, since
> > > > we require that it's a cleanly shut down cluster, so why are we
> > > > complaining about it if it's different..?
> > >
> > > Did you not read my previous email that we might have added this so we
> > > can upgrade replicas?
> >
> > I don't see how this option is related to dealing with replicas..?
> >
> > > I am sure I can dig out the commit that added
> > > this and find the original cause, but running pg_upgrade on replicas is
> > > enough of a reason to me.
> >
> > pg_upgrade can't be run on replicas, so I don't understand what you're
> > referring to here.. The 'upgrading replicas' process that involves
> > rsync also requires everything to have been shut down cleanly.
>
> Oh, I forgot we copy the WAL from the primary and don't run initdb on
> the standbys, so it might work, but looking at the pg_upgrade code, I
> see:
>
> /* now reset the wal archives in the new cluster */
> prep_status("Resetting WAL archives");
> exec_prog(UTILITY_LOG_FILE, NULL, true, true,
> /* use timeline 1 to match controldata and no WAL history file */
> "\"%s/pg_resetwal\" -l 00000001%s \"%s\"", new_cluster.bindir,
> old_cluster.controldata.nextxlogfile + 8,
> new_cluster.pgdata);
>
> So, while we don't copy over the old WAL, we do assume the WAL will be
> at the same segment from the old cluster. I think this is because of
> the LSN stored on user data pages. pg_resetwal doesn't seem to care
> about that, so maybe pg_upgrade doesn't need to either. I don't know.
Yeah, this would need to be adjusted, since we're passing in an actual WAL
filename there rather than an LSN.
> > > 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..
> The other modes don't work? I see this C comment:
>
> * We unconditionally start/stop the new server because pg_resetwal -o set
> * wal_level to 'minimum'. If the user is upgrading standby servers using
> * the rsync instructions, they will need pg_upgrade to write its final
> * WAL record showing wal_level as 'replica'.
Yes, the new system needs to have replica (or higher) as the wal_level,
but that doesn't depend on the WAL segment size.
Thanks,
Stephen
