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

From Robert Haas
Subject Re: increasing the default WAL segment size
Date
Msg-id CA+TgmoY0HBZhex0jsXgnDuCNDKdP10bRnGzWyas73EOXeJjb5A@mail.gmail.com
Whole thread Raw
In response to Re: increasing the default WAL segment size  (Stephen Frost <sfrost@snowman.net>)
Responses Re: increasing the default WAL segment size  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On Thu, Aug 25, 2016 at 9:48 AM, Stephen Frost <sfrost@snowman.net> wrote:
> * Robert Haas (robertmhaas@gmail.com) wrote:
>> Meanwhile, we'll significantly help people who are currently
>> generating painfully large but not totally insane numbers of WAL
>> segments.  Someone who is currently generating 32,768 WAL segments per
>> day - about one every 2.6 seconds - will have a significantly easier
>> time if they start generating 8,192 WAL segments per day - about one
>> every 10.5 seconds - instead.  It's just much easier for a reasonably
>> simple archive command to keep up, "ls" doesn't have as many directory
>> entries to sort, etc.
>
> I'm generally on-board with increasing the WAL segment size, and I can
> see the point that we might want to make it more easily configurable as
> it's valuable to set it differently on a small database vs. a large
> database, but I take exception with the notion that a "simple archive
> command" is ever appropriate.

My point wasn't really that archive_command should actually be simple.
My point was that if it's being run multiple times per second, there
are additional challenges that wouldn't arise if it were being run
only every 5-10 seconds.

I guess I should have said "simpler" rather than "reasonably simple",
because there's nothing simple about setting archive_command properly.
I mean, it could only actually be simple if somebody had a good a
backup tool that provided an archive_command that you could just drop
in place.  But I'm sure if somebody had such a tool, they'd take every
opportunity to bring it up, so we doubtless would have heard about it
by now.  Right?  :-)

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



pgsql-hackers by date:

Previous
From: Ivan Frolkov
Date:
Subject: UPSERT strange behavior
Next
From: Yury Zhuravlev
Date:
Subject: Why is a newly created index contains the invalidLSN?