Re: Big 7.1 open items

From: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>, "'Peter Eisentraut'" <peter_e(at)gmx(dot)net>, Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>, Jan Wieck <JanWieck(at)Yahoo(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, "Ross J(dot) Reedstrom" <reedstrm(at)rice(dot)edu>
Subject: Re: Big 7.1 open items
Date: 2000-06-28 23:53:03
Message-ID: 395A8FDF.1132EC6D@tpf.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:

> "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> writes:
> > Why do we have to have system tables per *database* ?
> > Is there anything wrong with global system tables ?
> > And how about adding dbid to pg_class,pg_proc etc ?
>
> We could, but I think I'd vote against it on two grounds:
>
> 1. Reliability. If something corrupts pg_class, do you want to
> lose your whole installation, or just one database?
>
> 2. Increased locking overhead/loss of concurrency. Currently, there
> is very little lock contention between backends running in different
> databases. A shared pg_class will be a single point of locking (as
> well as a single point of failure) for the whole installation.

Isn't current design of PG's *database* for dropdb using "rm -rf"
rather than for above 1.2. ?
If we couldn't rely on our db itself and our locking mechanism is
poor,we could start different postmasters for different *database*s.

> It would solve the DROP DATABASE problem kind of nicely, but really
> it'd just be downgrading DROP DATABASE to a DROP SCHEMA operation...
>

What is our *DATABASE* ?
Is it clear to all people ?
At least it's a vague concept for me.
Could you please tell me what kind of objects are our *DATABASE*
objects but could not be schema objects ?

Regards.

Hiroshi Inoue

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message dbahena 2000-06-29 00:31:59 regular expressions troubles with char cols
Previous Message Karel Zak 2000-06-28 19:40:35 Re: Misc. consequences of backend memory management changes