Skip site navigation (1) Skip section navigation (2)

BUG #5174: [minor] directories symlinked into base/ are not recursively removed

From: "Richard Neill" <rn214(at)cam(dot)ac(dot)uk>
To: pgsql-bugs(at)postgresql(dot)org
Subject: BUG #5174: [minor] directories symlinked into base/ are not recursively removed
Date: 2009-11-08 18:16:56
Message-ID: 200911081816.nA8IGufl033761@wwwmaster.postgresql.org (view raw or flat)
Thread:
Lists: pgsql-bugs
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
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

Responses

pgsql-bugs by date

Next:From: digital.death@gmx.itDate: 2009-11-08 21:19:17
Subject: odd lock on CREATE TABLE AS SELECT
Previous:From: digital.death@gmx.itDate: 2009-11-08 11:40:13
Subject: odd deadlock on CREATE TABLE AS SELECT

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group