From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Remove secondary checkpoint |
Date: | 2017-11-07 23:17:56 |
Message-ID: | CAB7nPqTeke3U2kcD8dABa9PgyH75-8GuVFR5NG75qgsQogEyPg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Nov 8, 2017 at 2:23 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On 31 October 2017 at 12:01, Michael Paquier <michael(dot)paquier(at)gmail(dot)com> wrote:
>> While the mention about a manual checkpoint happening after a timed
>> one will cause a full range of WAL segments to be recycled, it is not
>> actually true that segments of the prior's prior checkpoint are not
>> needed, because with your patch the segments of the prior checkpoint
>> are getting recycled. So it seems to me that based on that the formula
>> ought to use 1.0 instead of 2.0...
>
> I think the argument in the comment is right, in that
> CheckPointDistanceEstimate is better if we use multiple checkpoint
> cycles.
Yes, the theory behind is correct. No argument behind that.
> But the implementation of that is bogus and multiplying by 2.0
> wouldn't make it better if CheckPointDistanceEstimate is wrong.
Yes, this is wrong. My apologies if my words looked confusing. By
reading your message I can see that our thoughts are on the same page.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2017-11-07 23:21:49 | Re: Exclude pg_internal.init from base backup |
Previous Message | Peter Geoghegan | 2017-11-07 22:50:38 | Re: Small improvement to compactify_tuples |