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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: unnailing shared relations (was Re: global temporary tables)
Date: 2010-05-24 21:18:21
Message-ID: AANLkTil7dIn_pAt1smHVNGFVnZSfc3c_BaPEEuwhS-nw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, May 24, 2010 at 4:23 PM, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
> Excerpts from Robert Haas's message of vie may 21 10:20:38 -0400 2010:
>
>> Actually, there's another way we could do this.   Instead of creating
>> pg_shared_class and pg_shared_attribute and moving all of the catalog
>> entries for the shared relations into those tables, we could consider
>> leaving the catalog entries in the unshared copies of pg_class,
>> pg_attribute, etc. and DUPLICATING them in a shared catalog which
>> would only be used prior to selecting a database.  Once we selected a
>> database we'd switch to using the database-specific pg_class et al.
>> Obviously that's a little grotty but it might (?) be easier, and
>> possibly a step along the way.
>
> Uh, how does this work when you change the entries for shared relations
> in a database-specific pg_class?  Keeping everything in sync seems hard,
> if not impossible.

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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-05-24 21:20:09 Re: pg_upgrade docs
Previous Message Merlin Moncure 2010-05-24 21:04:10 Re: Hiding data in postgresql