From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | "Bossart, Nathan" <bossartn(at)amazon(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] pg_upgrade to clusters with a different WAL segment size |
Date: | 2017-11-13 22:32:38 |
Message-ID: | 20171113223237.ohwjzrgdpd5yjtg7@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2017-11-14 07:26:22 +0900, Michael Paquier wrote:
> On Tue, Nov 14, 2017 at 6:11 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> > Hm. I'm not really on-board with doing this in pg_upgrade. A more
> > logical place seems to be pg_resetwal or something - there's no need to
> > force a pg_upgrade cycle (which is pretty expensive on clusters with a
> > significant number of objects) for somebody that wants to change the
> > segment size of a cluster without changing the major version.
> > pg_resetwal or a new tool seems like a more appropriate places for this.
>
> pg_upgrade makes use of pg_resetwal, so I am assuming that what Nathan
> means is actually what you mean, so as pg_upgrade gains as well an
> option with the segment size which will wrap the pg_resetwal's call.
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.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2017-11-13 22:43:30 | Re: Typo in auth-scram.c |
Previous Message | Michael Paquier | 2017-11-13 22:26:22 | Re: [HACKERS] pg_upgrade to clusters with a different WAL segment size |