On 11/13/17, 5:09 PM, "Tom Lane" <tgl@sss.pgh.pa.us> wrote:
> Michael Paquier <michael.paquier@gmail.com> writes:
>> On Tue, Nov 14, 2017 at 7:32 AM, Andres Freund <andres@anarazel.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.
>>
>> Both positions can be defended. Note that some users like to have the
>> upgrade experience within one single command do as much as possible if
>> possible, and this may include the possibility to switch segment size
>> to make the tool more friendly. I definitely agree with your point to
>> make the low-level magic happen in pg_resetwal though. Having
>> pg_upgrade call that at will could be argued afterwards.
>
> 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.
Fair points. If we added an option to pg_resetwal, should we bother
trying to handle the WAL filename overlap that Jeremy mentioned? The
-l option gives us the ability to set the WAL starting address
manually, but it might not be terribly clear to end users that this is
something to watch out for.
Nathan