From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Redesigning checkpoint_segments |
Date: | 2015-01-03 08:56:47 |
Message-ID: | 54A7AECF.5000008@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 01/03/2015 12:28 AM, Josh Berkus wrote:
> On 01/02/2015 01:57 AM, Heikki Linnakangas wrote:
>> wal_keep_segments does not affect the calculation of CheckPointSegments.
>> If you set wal_keep_segments high enough, checkpoint_wal_size will be
>> exceeded. The other alternative would be to force a checkpoint earlier,
>> i.e. lower CheckPointSegments, so that checkpoint_wal_size would be
>> honored. However, if you set wal_keep_segments high enough, higher than
>> checkpoint_wal_size, it's impossible to honor checkpoint_wal_size no
>> matter how frequently you checkpoint.
>
> So you're saying that wal_keep_segments is part of the max_wal_size
> total, NOT in addition to it?
Not sure what you mean. wal_keep_segments is an extra control that can
prevent WAL segments from being recycled. It has the same effect as
archive_command failing for N most recent segments, if that helps.
> Just asking for clarification, here. I think that's a fine idea, I just
> want to make sure I understood you. The importance of wal_keep_segments
> will be fading as more people use replication slots.
Yeah.
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2015-01-03 09:29:03 | Re: Problems with approach #2 to value locking (INSERT ... ON CONFLICT UPDATE/IGNORE patch) |
Previous Message | Jeff Janes | 2015-01-03 05:59:27 | Re: replicating DROP commands across servers |