The following bug has been logged online:
Bug reference: 5174
Logged by: Richard Neill
Email address: rn214@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