Re: crash-recovery replay of CREATE TABLESPACE is broken in HEAD

Tom Lane wrote:
> 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.

Sorry for the delay. I didn't realize this was my code that was broken
until Heikki told me via IM.

The bug is that we can't replay mkdir()/symlink() and assume those will
always succeed. I looked at the createdb redo code and it basically
drops the directory before creating it.

The tablespace directory/symlink setup is more complex, so I just wrote
the attached patch to trigger a redo-'delete' tablespace operation
before the create tablespace redo operation.

Ignoring mkdir/symlink creation failure is not an option because the
symlink might point to some wrong location or something.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ None of us is going to be here forever. +