Tom Lane wrote:
> Heikki Linnakangas <hlinnaka@iki.fi> writes:
> > On Sat, 5 Mar 2005, Tom Lane wrote:
> >> xlog.c is a fairly random place to put that functionality. Didn't it
> >> strike any warning bells for you when you had to add so many new
> >> #includes? I'm not entirely sure where this should go, but not there.
>
> > Yeah actually it did, but I forgot about it along the way. How about
> > putting it in a file of its own in backend/catalog? There's some code that
> > also deals with the data directories. Or straight into backend/storage.
>
> Actually, you could make some case for putting it in utils/init/ beside
> flatfiles.c, which has got much the same sort of issues to deal with.
>
> I think though that we ought to first consider the question of whether
> we *want* this functionality. On reflection I'm fairly nervous about
> the idea of actually deleting anything during startup --- seems like a
> good recipe for turning small failures into large failures. But if
> we're not going to delete anything then it's questionable whether we
> need to code it like this at all. It'd certainly be easier and safer to
> examine these tables after the system is up and running normally.
Let's discuss this. The patch as submitted checks for unreferenced
files on bootup and reports them in the log file, but does not delete
them. That seems like the proper behavior. I think we delete from
pgsql_tmp on bootup, but we _know_ those aren't referenced.
What other user interface would trigger this if we did it after startup?
Wouldn't we have to lock pg_class against VACUUM while we scan the file
system, and are we sure we do things in pg_class or the file system
first consistently? It seems much more prone to error doing it while
the system is running.
I guess I am happy with just reporting during startup like the patch
does now.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073