Re: Utility database (Was: RE: Autovacuum in the backend) - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: Utility database (Was: RE: Autovacuum in the backend)
Date
Msg-id 6BCB9D8A16AC4241919521715F4D8BCE6C76CD@algol.sollentuna.se
Whole thread Raw
In response to Utility database (Was: RE: Autovacuum in the backend)  ("Dave Page" <dpage@vale-housing.co.uk>)
Responses Re: Utility database (Was: RE: Autovacuum in the backend)
List pgsql-hackers
> > But then dbas will block off access to that db, or drop it
> and we're
> > back to square one...
>
> Don't see why they would.  Let's review what we have here:
>
> Database        Function(s)
>
> template0        guaranteed-virgin template for CREATE DATABASE
>
> template1        installation-default template for
> CREATE DATABASE
>             default database to connect to for clients
>
> (I don't think I'm missing anything --- can anyone think of a
> purpose I have forgotten?)
>
> If we split template1's functions as
>
> template1        installation-default template for
> CREATE DATABASE
>
> default            default database to connect to
> for clients
>
> then it becomes fairly reasonable for DBAs to block access to
> template1 after they've installed any installation-default
> stuff they want in it.
> There isn't any particular reason to block access to
> "default", unless you don't want to have a shared database at
> all --- in which case you'd probably just drop it.

It wouldn't just be "default to connect to", it would also be "location
for tools to store cluster-wide information". Which makes pg_system a
slightly more reasonable name in that context, but i certainly have no
problem with "default" as a name.


> One argument against this is that it'd mean another copy of
> the system catalogs in a standard installation.  That's been
> running three to five megabytes over the last few releases.
> Disk space is pretty cheap these days, but we do get
> occasional complaints from people who wish the footprint was smaller.

As long as you can drop it without hosing your system completely, that
can always be a solution for the ppl who are that space constrained.

//Magnus


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Utility database (Was: RE: Autovacuum in the backend)
Next
From: Tom Lane
Date:
Subject: Re: Utility database (Was: RE: Autovacuum in the backend)