We are facing a problem in dropping a tablespace after crash recovery. The
recovery starts from the last checkpoint, but the tables that were created by
a transaction in a tablespace before the checkpoint are still lying around; the
transaction had not finished by the time of crash.
After recovery, when the app tries to drop the tablespace, the command fails
because the tablespace directory is not empty.
Solving this problem has become quite critical since the the platform where
Postgres is being used is supposed to run unattended. The problem is currently
being solved by an application specific kluge, which is highly undesirable as
this kluge might not work as the application evolves.
Has this problem been reported/discussed earlier? Any suggestions to avoid this
situation?
I have a hackish idea of listing files created by yet-to-be-committed transactions be
listed after every checkpoint so that the recovery code can remember to remove
such files if the creating transaction's commit record is not encountered
until end of recovery. But this would require every smgrcreate() to be communicated
to the BGWriter, and somehow make BGWriter forget this list when the transaction
commits.
Regards,
--
gurjeet.singh
@ EnterpriseDB - The Enterprise Postgres Company
http://www.EnterpriseDB.comsingh.gurjeet@{ gmail | yahoo }.com
Twitter/Skype: singh_gurjeet
Mail sent from my BlackLaptop device
