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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
