Skip site navigation (1) Skip section navigation (2)

Re: Big 7.1 open items

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>, "'Peter Eisentraut'" <peter_e(at)gmx(dot)net>, "'Hiroshi Inoue'" <Inoue(at)tpf(dot)co(dot)jp>, 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 16:11:40
Message-ID: 15787.962208700@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> If we put multiple database tables in the same directory, have we
> considered how to drop databases?  Right now we do rm -rf:

rm -rf will no longer work in a tablespaces environment anyway.
(Even if you kept symlinks underneath the DB directory, rm -rf
wouldn't follow them.)

DROP DATABASE will have to be implemented honestly: run through
pg_class and do a regular DROP on each user table.

Once you've got rid of the user tables, rm -rf should suffice to
get rid of the "home tablespace" as I've been calling it, with
all the system tables therein.

Now that you mention it, this is another reason why system tables for
each database have to live in a separate tablespace directory: there's
no other good way to do that final stage of DROP DATABASE.  The
DROP-each-table approach doesn't work for system tables (somewhere along
about the point where you drop pg_attribute, DROP TABLE itself would
stop working ;-)).

However I do see a bit of a problem here: since DROP DATABASE is
ordinarily executed by a backend that's running in a different database,
how's it going to read pg_class of the target database?  Perhaps it will
be necessary to fire up a sub-backend that runs in the target DB for
long enough to kill all the user tables.  Looking messy...

			regards, tom lane

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2000-06-28 16:22:35
Subject: Re: ./configure bug in CVS
Previous:From: Hannu KrosingDate: 2000-06-28 16:09:05
Subject: Re: MySQL has gone GPL

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group