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.com singh.gurj...@{ gmail | yahoo }.com Twitter/Skype: singh_gurjeet Mail sent from my BlackLaptop device
