RE: unsubscribe

-----Original Message-----
From: Jeremy Schneider [mailto:schneider(at)ardentperf(dot)com]
Sent: Friday, November 17, 2017 5:47 PM
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>; Andres Freund <andres(at)anarazel(dot)de>; Bossart, Nathan <bossartn(at)amazon(dot)com>; pgsql-hackers(at)postgresql(dot)org
Subject: 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.)