Prev: pgsql: Add support for TCPkeepalives on Windows, both for backend and
Next: multibyte charater set in levenshtein function
From: Tom Lane on 11 Jul 2010 19:37
I managed to crash the executor in the tablespace.sql test while working
on a 9.1 patch, and discovered that the postmaster fails to recover
from that. The end of postmaster.log looks like

LOG: all server processes terminated; reinitializing
LOG: database system was interrupted; last known up at 2010-07-11 19:30:07 EDT
LOG: database system was not properly shut down; automatic recovery in progress
LOG: consistent recovery state reached at 0/EE26F30
LOG: redo starts at 0/EE26F30
FATAL: directory "/home/postgres/pgsql/src/test/regress/testtablespace/PG_9.1_201004261" already in use as a tablespace
CONTEXT: xlog redo create ts: 127158 "/home/postgres/pgsql/src/test/regress/testtablespace"
LOG: startup process (PID 13914) exited with exit code 1
LOG: aborting startup due to startup process failure

It looks to me like those well-intentioned recent changes in this area
broke the crash-recovery case. Not good.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

 | 
Pages: 1
Prev: pgsql: Add support for TCPkeepalives on Windows, both for backend and
Next: multibyte charater set in levenshtein function