The following bug has been logged online: Bug reference: 5174 Logged by: Richard Neill Email address: rn...@cam.ac.uk PostgreSQL version: 8.4.1 Operating system: Linux Description: [minor] directories symlinked into base/ are not recursively removed Details:
This is rather a minor nit, but it might be a useful report. If not, sorry for wasting your time. Summary: If subdirectories of base/ are actually symlinks, then postgresql deletes just the symlink, not the directory. To reproduce: I had a system which was running out of disk space, and required a CLUSTER to recover some. However, there wasn't actually enough space to run the cluster operation. Therefore, I moved some of the larger subdirectories in base/ to a different partition and symlinked them back. For example: service postgresql stop cd /var/lib/postgresql/8.4/main/base/ mv 12345 /elsewhere ln -s /elsewhere/12345 . #repeat for a few directories. service postgresql start This allowed me to get the system running again, and to recover space on the main partition. On shutting down postgres again to clean up, I found that all the symlinks were gone (good), but that the directories on the /elsewhere partition were still all present, and full of (now-useless) data. The (possible) bug: I'd expect Postgresql to first follow the link, then recursively clean-out the linked directory; then delete the link, leaving (at most) an empty directory /elsewhere/12345 Actually, postgresql deleted the symlink, then left everything in /elsewhere unchanged. Comparison with rm: mkdir a touch a/b ln -s a c rm -rf c #c is deleted; a and b remain untouched, i.e. it does exactly the same thing that Postgresql did. Conclusion: I don't know if this is intentional; if not, then a minor RFE would be to fix it. Thanks for your help - Richard -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
