On Tue, May 21, 2013 at 4:44 AM, Simon Riggs si...@2ndquadrant.com wrote:
On 20 May 2013 20:06, Heikki Linnakangas hlinnakan...@vmware.com wrote:
It would be possible to redesign this with a special new reason, or we
could just use time as the reason, or we could just leave it.
Do nothing is
On 21 May 2013 15:29, Fujii Masao masao.fu...@gmail.com wrote:
Or, what about using CHECKPOINT_FORCE and just printing force?
Currently that checkpoint always starts because of existence of the
end-of-recovery record, but I think we should ensure that the checkpoint
always starts by using
On 19.05.2013 17:22, Simon Riggs wrote:
On 1 May 2013 10:05, Fujii Masaomasao.fu...@gmail.com wrote:
In HEAD, when the standby is promoted, recovery requests the checkpoint
but doesn't wait for its completion. I found the checkpoint starting log message
of this checkpoint looks odd as
On 20 May 2013 20:06, Heikki Linnakangas hlinnakan...@vmware.com wrote:
It would be possible to redesign this with a special new reason, or we
could just use time as the reason, or we could just leave it.
Do nothing is easy, though so are the others, so we can choose
anything we want. What
On 1 May 2013 10:05, Fujii Masao masao.fu...@gmail.com wrote:
In HEAD, when the standby is promoted, recovery requests the checkpoint
but doesn't wait for its completion. I found the checkpoint starting log
message
of this checkpoint looks odd as follows:
LOG: checkpoint starting:
I
Hi,
In HEAD, when the standby is promoted, recovery requests the checkpoint
but doesn't wait for its completion. I found the checkpoint starting log message
of this checkpoint looks odd as follows:
LOG: checkpoint starting:
I think something like the following is better.
LOG:
