The following bug has been logged online:
Bug reference: 5174
Logged by: Richard Neill
Email address: rn214(at)cam(dot)ac(dot)uk
PostgreSQL version: 8.4.1
Operating system: Linux
Description: [minor] directories symlinked into base/ are not
This is rather a minor nit, but it might be a useful report. If not, sorry
for wasting your time.
If subdirectories of base/ are actually symlinks, then postgresql deletes
just the symlink, not the directory.
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.
service postgresql stop
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
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
Actually, postgresql deleted the symlink, then left everything in /elsewhere
Comparison with rm:
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.
I don't know if this is intentional; if not, then a minor RFE would be to
Thanks for your help - Richard
pgsql-bugs by date
|Next:||From: email@example.com||Date: 2009-11-08 21:19:17|
|Subject: odd lock on CREATE TABLE AS SELECT|
|Previous:||From: firstname.lastname@example.org||Date: 2009-11-08 11:40:13|
|Subject: odd deadlock on CREATE TABLE AS SELECT|