Re: [HACKERS] pg_upgrade to clusters with a different WAL segment size

On Mon, Nov 13, 2017 at 3:09 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> On Tue, Nov 14, 2017 at 7:32 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>>> Even if that's the case, I fail to see why it'd be a good idea to have
>>> any sort of pg_upgrade integration here. We should make pg_resetwal's
>>> checks for this good enough, and not conflate something unrelated with
>>> pg_upgrade goals.
>
> FWIW, I agree with Andres' position here. I think the charter of
> pg_upgrade is to duplicate the old cluster as closely as it can,
> not to modify its configuration. A close analogy is that it does not
> attempt to upgrade extension versions while migrating the cluster.

Having pg_upgrade simply allow an upgrade where the WAL sizes don't match
between the old cluster and the new cluster seems fairly trivial.
pg_upgrade isn't
changing anything; it's just *not* requiring the new and old clusters
to match in this
way. I'll admit I'm much newer to postgresql than everyone else on
this list, but I
haven't yet thought of any technical reason this check is actually
needed. (Just the
WAL sequencing/naming concern I outlined earlier.)

Writing code to change the WAL size on an existing cluster will be a little more
complex. We will need to delete all WAL files and recreate them at the new
sizes. We will need to either (1) be absolutely sure that there was a
clean shutdown
or (2) copy WAL data from the old files to the new files. We will
need to think harder
through the issue of gaps being introduced in the sequence of WAL filenames and
effects on backup/recovery.

These two ideas don't seem mutually exclusive to me. If pg_upgrade
allows working
with different WAL sizes, it doesn't mean we can't still introduce a
utility to change the
WAL size on running clusters.

So yeah - having a utility command to change the WAL size on a running cluster
is a great idea. But why are we wanting to maintain a check in pg_upgrade
which doesn't actually seem technically necessary? Or am I missing something
that would break if the WAL sizes didn't match across two clusters when
pg_upgrade moved the data between them?

-Jeremy

--
http://about.me/jeremy_schneider

(Disclaimer: I work for AWS and my opinions are my own.)