Re: cache startup file - Mailing list pgsql-hackers

From Tom Lane
Subject Re: cache startup file
Date
Msg-id 12246.925591168@sss.pgh.pa.us
Whole thread Raw
In response to cache startup file  (Bruce Momjian <maillist@candle.pha.pa.us>)
List pgsql-hackers
Bruce Momjian <maillist@candle.pha.pa.us> writes:
> That sounds like a big win.  1/3 second is large.  If they vacuum a
> single table, and it is not a system table, can the removal be
> skipped?

I didn't do that; I just put an unconditional remove into vac_shutdown.
If you want to improve on that, be my guest ;-).

> Just one more question.  If you remove the cache file so the next
> backend creates it, could their be problems if another backend starts
> while the file is being created by another backend?

The code in relcache.c looks to be fairly robust --- if the file seems
to be broken (ie, ends early) it will go off and rebuild the file.
So I suppose you could get an extra rebuild in that scenario.

If you wanted to be really paranoid you could have the writing code
create the file under a temporary name (using the backend's PID) and
rename it into place when done; that'd prevent any kind of worry about
the wrong things happening if two backends write the file at the same
time.  But really, it shouldn't matter.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] 6.5 cvs ERROR: copyObject: don't know how to copy 604
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] views and group by (formerly: create view as selec