Re: increasing the default WAL segment size

From: David Steele <david(at)pgmasters(dot)net>
To: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: increasing the default WAL segment size
Date: 2017-04-06 23:07:33
Message-ID: 0632f141-80bf-9ca6-4b75-588c1e90ebb6@pgmasters.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 4/6/17 6:52 PM, Tomas Vondra wrote:
> On 04/06/2017 11:45 PM, David Steele wrote:
>>
>> How many people in the field are running custom builds of
>> Postgres? And of those, how many have changed the WAL segment size?
>> I've never encountered a non-standard segment size or talked to anyone
>> who has. I'm not saying it has *never* happened but I would venture to
>> say it's rare.
>
> I agree it's rare, but I don't think that means we can just consider the
> option as 'unsupported'. We're even mentioning it in the docs as a valid
> way to customize granularity of the WAL archival.
>
> I certainly know people who run custom builds, and some of them run with
> custom WAL segment size. Some of them are our customers, some are not.
> And yes, some of them actually patched the code to allow 256MB WAL
> segments.

I feel a little better knowing that *somebody* is doing it in the field.

>> Just because we don't change the default doesn't mean that others won't.
>> I still think testing for sizes other than 16MB is severely lacking and
>> I don't believe caveat emptor is the way to go.
>
> Aren't you mixing regression and performance testing? I agree we need to
> be sure all segment sizes are handled correctly, no argument here.

Not intentionally. Our standard test suite is only regression as far as
I can see. All the performance testing I've seen has been done ad hoc.

>> I don't have plans to add animals. I think we'd need a way to tell
>> 'make check' to use a different segment size for tests and then
>> hopefully reconfigure some of the existing animals.
>
> OK. My point was that we don't have that capability now, and the latest
> patch is not adding it either.

Agreed.

--
-David
david(at)pgmasters(dot)net

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2017-04-06 23:14:22 Re: [COMMITTERS] pgsql: Collect and use multi-column dependency stats
Previous Message Tom Lane 2017-04-06 23:01:32 Re: Time to change pg_regress diffs to unified by default?