From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Simplifying replication |
Date: | 2010-10-22 17:34:07 |
Message-ID: | 4CC1CB0F.7050006@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>> max_wal_size
>> min_wal_size
>
> [ scratches head... ] What's the functional effect of min_wal_size, exactly?
Replaces wal_keep_segments. The rename is to make the GUCs obviously
symmetrical, and to make it clear that the *meaning* of the variable has
changed.
>> Even better would be to replace min_wal_size with min_wal_time, which
>> would set a time span for the oldest WAL segment to be kept (up to
>> max_wal_size - 2). Hmmm. That doesn't seem that hard to implement.
>> Is it?
>
> Um, what happens when honoring min_wal_time conflicts with honoring
> max_wal_size?
When we get close enough to max_wal_size (we'll need a couple segments
of leeway, I think), we start recycling WAL segments even if they are
less that min_wal_time old. This is under the presumption that most
DBAs will prefer having the standby desyncrhonize to having the master
lock up due to running out of disk space. Presumably if such recycling
happens we'd also write a WARNING to the logs.
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
From | Date | Subject | |
---|---|---|---|
Next Message | David Fetter | 2010-10-22 18:00:54 | Re: Custom aggragation function that creates an array |
Previous Message | Tom Lane | 2010-10-22 17:24:48 | Re: Simplifying replication |