Using both 9.2.9 and 9_2_STABLE 9b468bcec15f1ea7433d4, I get a fairly reproducible startup failure.
What I was doing is restore a database from a base backup and roll it forward with a recovery.conf until it completes and starts up. Then I truncate an unlogged table and start repopulating it with a large slow 'insert into ...select from' query. While that is running, if I reboot the server, when it restarts it does not come back up initially. This is what I get in the log from the attempted restart: PST LOG: database system was interrupted; last known up at 2014-11-25 15:40:33 PST PST LOG: database system was not properly shut down; automatic recovery in progress PST LOG: redo starts at 84/EF000080 PST LOG: record with zero length at 84/EF09AE18 PST LOG: redo done at 84/EF09AD28 PST LOG: last completed transaction was at log time 2014-11-25 15:42:09.173599-08 PST LOG: checkpoint starting: end-of-recovery immediate PST LOG: checkpoint complete: wrote 103 buffers (0.2%); 0 transaction log file(s) added, 246 removed, 7 recycled; write=0.002 s, sync=0.020 s, total=0.526 s; sync files=51, longest=0.003 s, average=0.000 s PST FATAL: could not create file "base/16416/59288": File exists PST LOG: startup process (PID 2472) exited with exit code 1 PST LOG: aborting startup due to startup process failure oid2name doesn't show me any 59288, so I think it is the new copy of the unlogged table which is being created at the moment of the reboot. I can't distribute a tarball of this particular database. How would I go about debugging this? Should I track down the source of the FATAL and convert it to a PANIC so I can get a core dump to look at? A second attempt to start up the server completes successfully. Cheers, Jeff
