DROP TABLESPACE needs crash-resistance

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(dot)gurjeet(at){ gmail | yahoo }.com
Twitter/Skype: singh_gurjeet

Mail sent from my BlackLaptop device