Hello, > I think it can so happen that last checkpoint is with old timeline and there > are operations with new timeline which might have caused the problem Heikki > has seen.
I suppose to have seen that. After adding an SQL command to modify the DB on standby-B after passive(propagated?) promotion of standby-C, < pg_ctl -D data-standbyB promote --- > > pg_ctl -D data-standbyB -w promote > sleep 20 > psql -p 5433 postgres -c 'create table t (a int); checkpoint;' I saw following complaint from standby-C. > B 2013-05-09 17:00:06.019 JST 30268 LOG: checkpoint starting: immediate > force wait > C 2013-05-09 17:00:06.211 JST 30277 LOG: invalid magic number 0000 in log > segment 000000010000000000000005, offset 4169728 > C 2013-05-09 17:00:06.211 JST 30295 FATAL: terminating walreceiver process > due to administrator command > B 2013-05-09 17:00:06.219 JST 30268 LOG: checkpoint complete: wrote 18 > buffers (0.1%); 0 transaction log file(s) added, 0 removed, 0 recycled; > write=0.000 s, sync=0.157 s, total=0.199 s; sync files=13, longest=0.041 s, > average=0.012 s > CHECKPOINT > C 2013-05-09 16:41:33.974 JST 29624 LOG: record with zero length at 0/53F8B90 > C 2013-05-09 16:41:33.974 JST 29624 LOG: record with zero length at 0/53F8B90 > C 2013-05-09 16:41:38.980 JST 29624 LOG: record with zero length at 0/53F8B90 .. repeats forever .. This seems to be caused from a kind of timeline inconsistency at first glance.. Explicit checkpoint before the modification on Sby-B does not help. > psql -p 5433 postgres -c 'checkpoint;create table t (a int); checkpoint;' regards, -- Kyotaro Horiguchi NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
