Re: Redesigning checkpoint_segments

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Petr Jelinek <petr(at)2ndquadrant(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Venkata Balaji N <nag1010(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Redesigning checkpoint_segments
Date: 2015-06-28 21:17:57
Message-ID: 55906485.4040505@iki.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 06/26/2015 02:08 PM, Heikki Linnakangas wrote:
> I'm not sure what to do about this. With the attached patch, you get the
> same leisurely pacing with restartpoints as you get with checkpoints,
> but you exceed max_wal_size during recovery, by the amount determined by
> checkpoint_completion_target. Alternatively, we could try to perform
> restartpoints faster then checkpoints, but then you'll get nasty
> checkpoint I/O storms in recovery.

Ok, committed this patch. IMHO it's definitely better than the old
behaviour.

> A bigger change would be to write a WAL record at the beginning of a
> checkpoint. It wouldn't do anything else, but it would be a hint to
> recovery that there's going to be a checkpoint record later whose
> redo-pointer will point to that record. We could then start the
> restartpoint at that record already, before seeing the checkpoint record
> itself.
>
> I think the attached is better than nothing, but I'll take a look at
> that beginning-of-checkpoint idea. It might be too big a change to do at
> this point, but I'd really like to fix this properly for 9.5, since
> we've changed with the way checkpoints are scheduled anyway.

This would've been a much more complicated patch, so I dropped that
idea, for 9.5 anyway. Maybe later, but it's not urgent.

- Heikki

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2015-06-28 22:05:19 Re: Solaris testers wanted for strxfrm() behavior
Previous Message Corey Huinker 2015-06-28 20:43:10 Re: proposal: condition blocks in psql