Could not read from file "pg_clog/0003" at offset 163840: Success

最近做postgresql+drbd+heartbeat，在primary机突然断电后，slave机切换为primary正常，但数据库无法启动，错误如下：

frank@node1:~/cas/bin$ sudo /etc/init.d/postgresql start 
 * Starting PostgreSQL 9.3 database server
 * The PostgreSQL server failed to start. Please check the log output:
2017-11-29 17:12:01 CST LOG:  database system was interrupted; last known up at 2017-11-29 16:55:13 CST
2017-11-29 17:12:01 CST LOG:  database system was not properly shut down; automatic recovery in progress
2017-11-29 17:12:01 CST LOG:  record with zero length at 6/1C8E33B0
2017-11-29 17:12:01 CST LOG:  redo is not required
2017-11-29 17:12:01 CST FATAL:  could not access status of transaction 3805721
2017-11-29 17:12:01 CST DETAIL:  Could not read from file "pg_clog/0003" at offset 163840: Success.
2017-11-29 17:12:01 CST LOG:  startup process (PID 3452) exited with exit code 1
2017-11-29 17:12:01 CST LOG:  aborting startup due to startup process failure

经查询资料，参考网友对类似问题的回复（url: https://www.postgresql.org/message-id/[e-mail]）：

You need to make the files the right size (256K of zeroes).A suitable "dd" from /dev/zero will accomplish this on modernUnixen (ie, anything that has /dev/zero).Note that this is by no means a fix, it simply allows pg_dump tocomplete.  What you are really doing by filling those files withzeroes is saying "assume all these old transactions aborted".You *will* have data loss.  It will only affect rows that haven'tbeen accessed in a very long time (since at least June, looks like)but gone is gone.Another possibility that might be better is to fill the files with0x55, though this is harder since /dev/zero won't help.  That wouldforce all the old transactions to be considered committed rather thanaborted.  This isn't really better from a consistency standpoint, butif you feel that most of your data-altering commands succeed thenthis might give you a closer approximation to the state you want.The whole thing is pretty troubling because 8.2.x is supposed tocontain defenses against this type of problem.  Could we seethe contents of "select datname, datfrozenxid from pg_database"?Also, have you tried dumping individual databases instead ofpg_dumpall?  (It would be good to experiment with that beforeyou start making bogus pg_clog files; once you do that there'sno going back in terms of recovering the true state of your data.)

执行如下命令后问题解决（虽然可能丢失部分数据，但对我来说可以接受）：

sudo dd if=/dev/zero of=/rep/postgresql/data/pg_clog/0003 bs=1k count=256