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.