Re: Improving backend launch time by preloading relcache

Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> writes:
> REINDEX uses the relfilenode mechanism since 7.1 which
> lets the replacement of index files be under transactional
> control. I think it's safe enough.

Okay, in that case tcop/utility is being too picky about all three
cases, no?

> What I meant was to confirm if it's really reliable.
> Currently e.g. the failure of rename of temporary
> init file to pg_internal.init isn't fatal but it
> may be fatal if we include many relcache info in
> the pg_internal.init file.

Certainly not --- it must always be possible for a freshly started
backend to build the pg_internal.init file from scratch. The reason
for unlinking pg_internal.init after changing a catalog schema tuple
is that future backends won't know you changed it unless
pg_internal.init is rebuilt.

Hmm ... what that says is that unlinking pg_internal.init in
setRelfilenode is the wrong place. The right place is *after*
committing your transaction and *before* sending shared cache inval
messages. You can't unlink before you commit, or someone may rebuild
using the old information. (A backend that's already logged into the
PROC array when you send SI inval will find out about the changes via SI
inval. One that is not yet logged in must be prevented from reading the
now-obsolete pg_internal.init file. The startup sequence logs into PROC
before trying to read pg_internal.init, so that part is done in the
right order.) So we need a flag that will cause the unlink to happen at
the right time in post-commit cleanup.

VACUUM's got this same timing bug, although its change is only one of
updating relpages/reltuples which is not so critical...

regards, tom lane