Tom Lane wrote:
There's also the plan B of scanning pg_class to decide which relfilenode
values are legit. IIRC Bruce did up a patch for this about a year ago,
which I vetoed because I was afraid of the consequences if it removed
data that someone really needed. Someone just mentioned doing the same
thing but pushing the unreferenced files into a "trash" directory
instead of actually deleting them. While that answers the
risk-of-data-loss objection, I'm not sure it does much for the goal of
avoiding useless space consumption: how many DBAs will faithfully
examine and clean out that trash directory?
For the admin who for some reason deletes critical input data before
seeing a COMMIT return from postgresql they can probably keep the files.
The thing is, the leak occurs in situation where a COMMIT hasn't
returned to the user, so we are trying to guarantee no data-loss even
when the user doesn't see a successful commit? That's a tall order
obviously and hopefully people design their apps to attend to
transaction success / failure.
Plan B certainly won't take more space, and is probably the easiest to
cleanup.
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
