On 3/25/18, 2:02 PM, "Peter Eisentraut"
wrote:
> committed
Thanks!
Nathan
On 3/21/18 17:14, Bossart, Nathan wrote:
> Here is an updated set of patches that use the newly proposed approach
> for avoiding division-by-zero errors in pg_resetwal.
committed
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Traini
On 3/21/18, 12:57 PM, "Peter Eisentraut"
wrote:
> On 3/13/18 20:53, Bossart, Nathan wrote:
>> 0001: Fix division-by-zero error in pg_controldata
>
> committed that
Thanks!
>> 0002: Fix division-by-zero error in pg_resetwal
>
> This looks a bit more complicated than necessary to me. I think
On 3/13/18 20:53, Bossart, Nathan wrote:
> Here is a new set of patches that addresses most of Peter's feedback.
> I've split it into four pieces:
>
> 0001: Fix division-by-zero error in pg_controldata
committed that
> 0002: Fix division-by-zero error in pg_resetwal
This looks a bit more co
Thanks for taking a look.
On 3/3/18, 12:22 PM, "Peter Eisentraut"
wrote:
> On 2/7/18 13:34, Bossart, Nathan wrote:
>> Here is a patch to allow users to change the WAL segment size of a cluster
>> with
>> pg_resetwal. Like the '--wal-segize' option in initdb, the new '-s' option
>> accepts segm
On 2/7/18 13:34, Bossart, Nathan wrote:
> Here is a patch to allow users to change the WAL segment size of a cluster
> with
> pg_resetwal. Like the '--wal-segize' option in initdb, the new '-s' option
> accepts segment sizes in megabytes.
Or how about we call the new option, um, --wal-segsize?
On Fri, Nov 17, 2017 at 5:46 PM, Jeremy Schneider
wrote:
> 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.
...
> Writing code to change the WAL size on an existing cluster will be a little
> more
> compl
On Mon, Nov 13, 2017 at 3:09 PM, Tom Lane wrote:
>> On Tue, Nov 14, 2017 at 7:32 AM, Andres Freund 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
On Tue, Nov 14, 2017 at 8:38 AM, Bossart, Nathan wrote:
> 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 te
On 11/13/17, 5:09 PM, "Tom Lane" wrote:
> Michael Paquier writes:
>> On Tue, Nov 14, 2017 at 7:32 AM, Andres Freund 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 goo
Michael Paquier writes:
> On Tue, Nov 14, 2017 at 7:32 AM, Andres Freund 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
On Tue, Nov 14, 2017 at 7:32 AM, Andres Freund wrote:
> On 2017-11-14 07:26:22 +0900, Michael Paquier wrote:
>> On Tue, Nov 14, 2017 at 6:11 AM, Andres Freund 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 - th
On 2017-11-14 07:26:22 +0900, Michael Paquier wrote:
> On Tue, Nov 14, 2017 at 6:11 AM, Andres Freund 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 pret
On Tue, Nov 14, 2017 at 6:11 AM, Andres Freund 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 objec
Hi,
On 2017-11-10 15:46:11 +, Bossart, Nathan wrote:
> The thread for the recent change to allow setting the WAL segment size at
> initdb time [0] included a bit of discussion regarding pg_upgrade [1],
> where it was suggested that relaxing an error check (presumably in
> check_control_data())
On Fri, Nov 10, 2017 at 4:04 PM, Michael Paquier
wrote:
> On Sat, Nov 11, 2017 at 12:46 AM, Bossart, Nathan wrote:
>> Allowing changes to the WAL segment size during pg_upgrade seems like a
>> nice way to avoid needing a dump and load, so I would like to propose
>> adding support for this. I'd b
16 matches
Mail list logo
