Re: Relation locking and relcache load (was Re: Going for "all green" buildfarm results)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Relation locking and relcache load (was Re: Going for "all green" buildfarm results)
Date: 2006-07-30 21:19:04
Message-ID: 3887.1154294344@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> ... This means the only thing stopping us from
> taking lock before we invoke relcache is lack of knowledge about the
> rel's relisshared status. Given that the set of shared relations is
> pretty small, and fixed in any given backend version, it wouldn't be
> unreasonable to handle this by keeping a hardwired list of shared
> relation OIDs somewhere in the backend.

On further investigation, there is one small stumbling block in that
plan. We currently have hard-wired OIDs for shared catalogs and their
indexes ... but not for their toast tables (nor the indexes thereon).

I think the best solution for this might be to put the responsibility
for creating system catalogs' toast tables into the bootstrap phase
instead of making initdb do it afterwards. This would be a Good Thing
anyway since currently we are incapable of dealing with bootstrap-time
insertions of values large enough to need toasting. I'm imagining
adding macros to the include/catalog/*.h files along the lines of

TOAST_CATALOG(pg_class,4242,4243)

where the numbers are hand-assigned OIDs for the toast table and index.
The existing mechanisms for creating the .bki bootstrap script would
turn these into commands in the .bki script.

We could then get rid of ALTER TABLE ... CREATE TOAST TABLE as a SQL
command altogether, which seems like a good thing to me. Anyone want to
argue for keeping it? There really shouldn't be any case where a user
needs to invoke it.

Thoughts, objections?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2006-07-30 21:23:23 Let psql process files with > 4,294,967,295 lines
Previous Message Tom Lane 2006-07-30 20:35:51 Re: problem with volatile functions in subselects ?