Re: Patch to remove/report orphaned files

> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > The only issue with oid wraparound is that it will not report orphaned
> > files from the last vacuum to the wraparound time, which seems OK.
>
> s/seems OK/means that it's completely useless once wrap has occurred/.
> Moreover, it will start complaining about freshly-created files whose
> pg_class rows aren't committed yet. Checking OID in this way is simply
> wrong, and we should not install such a kluge without an overwhelming
> reason to do it. I see no overwhelming need for this thing. In fact,
> I'm not convinced that there's any need for it.

I don't get it. How would wrap cause it to complain about new files?
It is getting the minimum oid at startup plus the minimum current
counter. Are you saying it wraps while I am checking? That would be a
problem. I need to check that the oid counter is not wrapped before
printing each message.

After a wrap, you would have files greater than the current oid, but
that is not a problem because I would not be looking at them. In fact,
how do we handle wrap with filenames based on oid?

> > We don't know problems we have with orphaned files because we don't
> > detect them now. We know we have left over sort files because people
> > complain about them, so odds are we have these others out there too.
>
> Two points about that. One, this won't detect them with any
> reliability; what it will do is generate false, impossible-to-reproduce
> problem reports --- maybe even induce DBAs to manually delete files that
> they needed. ("The message says file 543242 is orphan, so I can get
> rid of it without checking further.") Two, we don't know that we still
> have such a problem in current sources. The orphaned-sort-file reports
> that I remember are all from pre 7.0, when we didn't have a mechanism
> that would clean them out after elog(ERROR). I don't think there is
> evidence to justify that we still need such a detector. We certainly
> don't need it bad enough to justify installing a not-quite-correct kluge.

Certainly we have cases where these files will be created no matter how
hard we check. Power off during table creation should produce them,
right?

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026