Hello, 2014/02/28 18:07 "Andres Freund" : > > On 2014-02-28 17:55:21 +0900, Kyotaro HORIGUCHI wrote: > > The recovery process stays on 'incosistent' state forever when > > the server has crashed before any wal record is inserted after > > the last checkpoint. > > > # killall postgres > > # rm -rf $PGDATA/* > > initdb > > pg_ctl start -w > > sleep 1 > > pg_ctl stop -m i > > cat > $PGDATA/recovery.conf <<EOF > > standby_mode = 'on' > > primary_conninfo = 'host=localhost port=9999 user=repuser application_name=pm01 keepalives_idle=60 keepalives_interval=5 keepalives_count=5' > > #restore_command = '/bin/true' > > recovery_target_timeline = 'latest' > > EOF > > cat >> $PGDATA/postgresql.conf <<EOF > > #log_min_messages = debug5 > > hot_standby = on > > EOF > > pg_ctl start > > Uh. So, if I understand correctly, what you did is to convert a normal > live pg, into a replica that doesn't have a upstream node, right?
Yes, but the same stuation could be made by restarting crashed secondary. I didn't tried it since my console is far behind now... Can a restart of secondry after crashing just after the completion of restartpoint with no further records make the same situation? I have no idea about the scenario on whitch this behavior was regarded as undesirable but anyway I think that the secondry should start accepting client just after crash recovery is completed. > Normally the primary will just do an additional write shortly > afterwards, resolving this situation? Maybe so. I haven't tried though. regards, -- Kyotaro Horiguchi NTT Opensource Software Center
