Re: Skip checkpoint on promoting from streaming replication
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Heikki Linnakangas <hlinnakangas@vmware.com>
Cc: Simon Riggs <simon@2ndQuadrant.com>, Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>, masao.fujii@gmail.com, pgsql-hackers@postgresql.org
Date: 2013-01-25T15:20:07Z
Lists: pgsql-hackers
Heikki Linnakangas <hlinnakangas@vmware.com> writes: > There's no hard correctness reason here for any particular behavior, I > just feel that that would make most sense. It seems prudent to initiate > a checkpoint right after timeline switch, so that you get a new > checkpoint on the new timeline fairly soon - it could take up to > checkpoint_timeout otherwise, but there's no terrible rush to finish it > ASAP. +1. The way I would think about it is that we're switching from a checkpointing regime appropriate to a slave to one appropriate to a master. If the last restartpoint was far back, compared to the configured checkpoint timing for master operation, we're at risk that a crash could take longer than desired to recover. So we ought to embark right away on a fresh checkpoint, but do it in the same way it would be done in normal master operation (thus, not immediate). Once it's done we'll be in the expected checkpointing state for a master. regards, tom lane