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
