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

Reply via email to