Re: [HACKERS] increasing the default WAL segment size - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] increasing the default WAL segment size
Date
Msg-id CA+TgmobqCY9A3zHL-wJFT0w3puVdCwe91gxVMnvy2MZRu_df=w@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] increasing the default WAL segment size  (Stephen Frost <sfrost@snowman.net>)
Responses Re: [HACKERS] increasing the default WAL segment size  (David Steele <david@pgmasters.net>)
Re: [HACKERS] increasing the default WAL segment size  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
On Tue, Mar 21, 2017 at 9:04 AM, Stephen Frost <sfrost@snowman.net> wrote:
> In short, I'm also concerned about this change to make WAL file names no
> longer match up with LSNs and also about the odd stepping that you get
> as a result of this change when it comes to WAL file names.

OK, that's a bit surprising to me, but what do you want to do about
it?  If you take the approach that Beena did, then you lose the
correspondence with LSNs, which is admittedly not great but there are
already helper functions available to deal with LSN -> filename
mappings and I assume those will continue to work. If you take the
opposite approach, then WAL filenames stop being consecutive, which
seems to me to be far worse in terms of user and tool confusion.  Also
note that, both currently and with the patch, you can also reduce the
WAL segment size.  David's proposed naming scheme doesn't handle that
case, I think, and I think it would be all kinds of a bad idea to use
one file-naming approach for segments < 16MB and a separate approach
for segments > 16MB.  That's not making anything easier for users or
tool authors.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] GUC for cleanup indexes threshold.
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] Enabling parallelism for queries coming from SQL orother PL functions