Re: [PATCH] Lazy xid assingment V2

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.