Re: [HACKERS] pg_upgrade to clusters with a different WAL segmentsize - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: [HACKERS] pg_upgrade to clusters with a different WAL segmentsize
Date
Msg-id d417a057-5de9-00db-206c-dc50ed12bda6@2ndquadrant.com
Whole thread Raw
In response to Re: [HACKERS] pg_upgrade to clusters with a different WAL segmentsize  ("Bossart, Nathan" <bossartn@amazon.com>)
Responses Re: [HACKERS] pg_upgrade to clusters with a different WAL segmentsize  ("Bossart, Nathan" <bossartn@amazon.com>)
List pgsql-hackers
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?

> The first is a division-by-zero error caused when the control data must be
> guessed.  If the control data is damaged, WalSegSz will not be set to the
> guessed WAL segment size, resulting in an error during XLogFromFileName().  The
> attached patch resolves this issue by ensuring WalSegSz is set to a valid value
> after either reading or guessing the control values.

I noticed this issue in pg_controldata too.  Maybe that should be
combined in a separate patch.

> Note that some segment size changes will cause old WAL file names to be reused.
> The new documentation for '-s' contains a note warning of this side effect.  I
> considered a couple of strategies to prevent this, but I chose not to include
> any in the patch based on previous correspondence in this thread.  If file name
> overlap is an issue, users can already use the '-l' option to set a safe WAL
> starting address.

The patch "Configurable file mode mask" contains the beginning of a test
suite for pg_resetwal.  It would be great if we could get a test case
for this new functionality implemented.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


pgsql-hackers by date:

Previous
From: Arthur Zakirov
Date:
Subject: Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs
Next
From: Magnus Hagander
Date:
Subject: Re: Online enabling of checksums