Horton
Menu

Re: increasing the default WAL segment size

David Steele <david@pgmasters.net>

View thread
From: David Steele <david@pgmasters.net>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Stephen Frost <sfrost@snowman.net>, Robert Haas <robertmhaas@gmail.com>
Cc: Beena Emerson <memissemerson@gmail.com>, tushar <tushar.ahuja@enterprisedb.com>, Prabhat Sahu <prabhat.sahu@enterprisedb.com>, Ashutosh Sharma <ashu.coek88@gmail.com>, Jim Nasby <Jim.Nasby@bluetreble.com>, Kuntal Ghosh <kuntalghosh.2007@gmail.com>, Andres Freund <andres@anarazel.de>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2017-03-24T13:44:34Z
Lists: pgsql-hackers 
On 3/23/17 4:45 PM, Peter Eisentraut wrote:
> On 3/22/17 17:33, David Steele wrote:
>> I think if we don't change the default size it's very unlikely I would
>> use alternate WAL segment sizes or recommend that anyone else does, at
>> least in v10.
>>
>> I simply don't think it would get the level of testing required to be
>> production worthy
>
> I think we could tweak the test harnesses to run all the tests with
> different segment sizes.  That would get pretty good coverage.

I would want to see 1,16,64 at a minimum.  More might be nice but that 
gets a bit ridiculous at some point.  I would be fine with different 
critters having different defaults.  I don't think that each critter 
needs to test each value.

> More generally, the methodology that we should not add an option unless
> we also change the default because the option would otherwise not get
> enough testing is a bit dubious.

Generally, I would agree, but I think this is a special case.  This 
option has been around for a long time and we are just now exposing it 
in a way that's useful to end users.  It's easy to see how various 
assumptions may have arisen around the default and led to code that is 
not quite right when using different values.  Even if that's not true in 
the backend code, it might affect bin, and certainly affects third party 
tools.

-- 
-David
david@pgmasters.net

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Make WAL segment size configurable at initdb time.

  2. Perform only one ReadControlFile() during startup.

  3. Introduce BYTES unit for GUCs.

  4. Remove useless duplicate inclusions of system header files.

  5. Refactor other replication commands to use DestRemoteSimple.

  6. Add a SHOW command to the replication command language.

  7. Add a new DestReceiver for printing tuples without catalog access.

  8. Support fls().

  9. Extend yesterday's patch making BLCKSZ and RELSEG_SIZE configurable to also

  10. Commit the reasonably uncontroversial parts of J.R. Nield's PITR patch, to

  11. XLOG (also known as WAL -:)) Bootstrap/Startup/Shutdown.

  12. Transaction log manager core code.