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