On 21 May 2013 15:29, Fujii Masao 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 that flag.
This wo
On Tue, May 21, 2013 at 4:44 AM, Simon Riggs wrote:
> On 20 May 2013 20:06, Heikki Linnakangas 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 othe
On 20 May 2013 20:06, Heikki Linnakangas 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 do we want it
On 19.05.2013 17:22, Simon Riggs wrote:
On 1 May 2013 10:05, Fujii Masao 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: checkpoi
On 1 May 2013 10:05, Fujii Masao 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 think somethi
