Robert Haas escribió:
> [smgr.c,inval.c] Do we need to call CacheInvalidSmgr for temporary
> relations? I think the only backend that can have an smgr reference
> to a temprel other than the owning backend is bgwriter, and AFAICS
> bgwriter will only have such a reference if it's responding to a
> request by the owning backend to unlink the associated files, in which
> case (I think) the owning backend will have no reference.
Hmm, wasn't there a proposal to have the owning backend delete the files
instead of asking the bgwriter to?
> [dbsize.c] As with relcache.c, there's a problem if we're asked for
> the size of a temporary relation that is not our own: we can't call
> relpath() without knowing the ID of the owning backend, and there's no
> way to acquire that information for pg_class. I guess we could just
> refuse to answer the question in that case, but that doesn't seem real
> cool. Or we could physically scan the directory for files that match
> a suitably constructed wildcard, I suppose.
I don't very much like the wildcard idea; but I don't think it's
unreasonable to refuse to provide a file size. If the owning backend
has still got part of the table in local buffers, you'll get a
misleading answer, so perhaps it's best to not give an answer at all.
Maybe this problem could be solved if we could somehow force that
backend to write down its local buffers, in which case it'd be nice to
have a solution to the dbsize problem.
> [syncscan.c] It seems we pursue this optimization even for temprels; I
> can't think of why that would be useful in practice. If it's useless
> overhead, should we skip it? This is really independent of this
> project; just a side thought.
Maybe recently used buffers are more likely to be in the OS page cache,
so perhaps it's not good to disable it.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.