Re: [HACKERS] fast promotion and log_checkpoints

2013-05-21 Thread Fujii Masao
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

Re: [HACKERS] fast promotion and log_checkpoints

2013-05-21 Thread Simon Riggs
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

Re: [HACKERS] fast promotion and log_checkpoints

2013-05-20 Thread Heikki Linnakangas
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

Re: [HACKERS] fast promotion and log_checkpoints

2013-05-20 Thread Simon Riggs
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

Re: [HACKERS] fast promotion and log_checkpoints

2013-05-19 Thread Simon Riggs
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