Re: Skip checkpoint on promoting from streaming replication

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
Cc: Simon Riggs <simon(at)2ndQuadrant(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, masao(dot)fujii(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Skip checkpoint on promoting from streaming replication
Date: 2013-01-25 15:20:07
Message-ID: 11546.1359127207@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Heikki Linnakangas <hlinnakangas(at)vmware(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2013-01-25 15:24:33 Using COPY FREEZE with pg_restore --single-transaction
Previous Message Bruce Momjian 2013-01-25 15:05:31 Re: Minor inheritance/check bug: Inconsistent behavior