Re: unnailing shared relations (was Re: global temporary tables)

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, May 24, 2010 at 5:37 PM, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
>> Excerpts from Robert Haas's message of lun may 24 17:18:21 -0400 2010:
>>> Well, I might be missing something here, but pg_class already IS
>>> database-specific. If you change anything very significant about a
>>> shared rel in one copy of pg_class today, you're toast, IIUC. This
>>> proposal doesn't make that any better, but I don't think it makes it
>>> any worse either.
>>
>> I thought the whole point of this exercise was precisely to avoid this
>> sort of problem.

> Short answer: Nope.

In practice, it's very difficult to change anything about a system
catalog anyway, because so many of its properties are baked into the
behavior of the C code. Whether there's a single copy of the catalog
rows is the least of your worries there.

> Long answer: It would be nice to do that, but in order to accomplish
> that we would need to create pg_shared_<foo> for all relevant pg_<foo>
> and teach the backend code to check both tables in every case. That
> seemed hard, so I suggested just duplicating the entries, thereby
> giving processes like the autovacuum launcher the ability to look at
> any shared relation without it needing to be nailed, but not actually
> solving the whole problem.

I hadn't been paying that much attention to this thread, but it's
sounding to me like it's based on a false premise. Having a shared copy
of the catalog entries for a shared catalog would accomplish little or
nothing in terms of eliminating nailed relcache entries. You might be
able to de-nail pg_database and friends, but only at the cost of instead
nailing up entries for "pg_shared_class" and friends. Which seems to me
like a net step backwards in terms of the maintenance overhead for
relcache entries.

If we really cared about not nailing these (and I'm not aware of any
evidence that we should care), it would probably be more useful to try
to institute an intermediate level of nailing ("stapling"?
"scotch-taping"?) that locked the entry into memory only until we'd
finished bootstrapping the backend.

regards, tom lane