2000-03-31 05:27:42 +02:00
|
|
|
<!--
|
2004-11-05 20:17:13 +01:00
|
|
|
$PostgreSQL: pgsql/doc/src/sgml/manage-ag.sgml,v 2.36 2004/11/05 19:15:49 tgl Exp $
|
2000-03-31 05:27:42 +02:00
|
|
|
-->
|
|
|
|
|
2000-06-30 18:14:21 +02:00
|
|
|
<chapter id="managing-databases">
|
|
|
|
<title>Managing Databases</title>
|
|
|
|
|
2001-11-12 20:19:39 +01:00
|
|
|
<indexterm zone="managing-databases"><primary>database</></>
|
|
|
|
|
2000-06-30 18:14:21 +02:00
|
|
|
<para>
|
2002-11-15 04:11:18 +01:00
|
|
|
Every instance of a running <productname>PostgreSQL</productname>
|
|
|
|
server manages one or more databases. Databases are therefore the
|
|
|
|
topmost hierarchical level for organizing <acronym>SQL</acronym>
|
|
|
|
objects (<quote>database objects</quote>). This chapter describes
|
|
|
|
the properties of databases, and how to create, manage, and destroy
|
|
|
|
them.
|
2000-06-30 18:14:21 +02:00
|
|
|
</para>
|
|
|
|
|
2003-03-13 02:30:29 +01:00
|
|
|
<sect1 id="manage-ag-overview">
|
2002-09-25 23:16:10 +02:00
|
|
|
<title>Overview</title>
|
|
|
|
|
2003-08-31 19:32:24 +02:00
|
|
|
<indexterm zone="manage-ag-overview">
|
|
|
|
<primary>schema</primary>
|
|
|
|
</indexterm>
|
|
|
|
|
2000-06-30 18:14:21 +02:00
|
|
|
<para>
|
2002-11-15 04:11:18 +01:00
|
|
|
A database is a named collection of <acronym>SQL</acronym> objects
|
|
|
|
(<quote>database objects</quote>). Generally, every database
|
|
|
|
object (tables, functions, etc.) belongs to one and only one
|
|
|
|
database. (But there are a few system catalogs, for example
|
2003-03-13 02:30:29 +01:00
|
|
|
<literal>pg_database</>, that belong to a whole cluster and
|
|
|
|
are accessible from each database within the cluster.) More
|
2002-11-15 04:11:18 +01:00
|
|
|
accurately, a database is a collection of schemas and the schemas
|
|
|
|
contain the tables, functions, etc. So the full hierarchy is:
|
2004-08-07 21:02:43 +02:00
|
|
|
server, database, schema, table (or some other kind of object,
|
|
|
|
such as a function).
|
2000-06-30 18:14:21 +02:00
|
|
|
</para>
|
|
|
|
|
2002-09-25 23:16:10 +02:00
|
|
|
<para>
|
|
|
|
An application that connects to the database server specifies in
|
|
|
|
its connection request the name of the database it wants to connect
|
|
|
|
to. It is not possible to access more than one database per
|
|
|
|
connection. (But an application is not restricted in the number of
|
|
|
|
connections it opens to the same or other databases.) It is
|
|
|
|
possible, however, to access more than one schema from the same
|
|
|
|
connection. Schemas are a purely logical structure and who can
|
|
|
|
access what is managed by the privilege system. Databases are
|
|
|
|
physically separated and access control is managed at the
|
2002-11-15 04:11:18 +01:00
|
|
|
connection level. If one <productname>PostgreSQL</> server
|
|
|
|
instance is to house projects or users that should be separate and
|
|
|
|
for the most part unaware of each other, it is therefore
|
|
|
|
recommendable to put them into separate databases. If the projects
|
|
|
|
or users are interrelated and should be able to use each other's
|
|
|
|
resources they should be put in the same databases but possibly
|
|
|
|
into separate schemas. More information about managing schemas is
|
2003-03-25 17:15:44 +01:00
|
|
|
in <xref linkend="ddl-schemas">.
|
2002-09-25 23:16:10 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<note>
|
|
|
|
<para>
|
2004-08-07 21:02:43 +02:00
|
|
|
The <acronym>SQL</> standard calls databases <quote>catalogs</>, but there
|
|
|
|
is no difference in practice.
|
2002-09-25 23:16:10 +02:00
|
|
|
</para>
|
|
|
|
</note>
|
|
|
|
</sect1>
|
2000-06-30 18:14:21 +02:00
|
|
|
|
2000-09-29 22:21:34 +02:00
|
|
|
<sect1 id="manage-ag-createdb">
|
2000-06-30 18:14:21 +02:00
|
|
|
<title>Creating a Database</title>
|
1999-06-23 08:15:37 +02:00
|
|
|
|
2002-09-25 23:16:10 +02:00
|
|
|
<para>
|
2004-08-07 21:02:43 +02:00
|
|
|
In order to create a database, the <productname>PostgreSQL</>
|
2002-09-25 23:16:10 +02:00
|
|
|
server must be up and running (see <xref
|
|
|
|
linkend="postmaster-start">).
|
|
|
|
</para>
|
|
|
|
|
1999-06-23 08:15:37 +02:00
|
|
|
<para>
|
2004-08-07 21:02:43 +02:00
|
|
|
Databases are created with the SQL command
|
2004-08-07 21:14:45 +02:00
|
|
|
<xref linkend="sql-createdatabase">:<indexterm><primary>CREATE
|
2004-08-07 21:02:43 +02:00
|
|
|
DATABASE</></>
|
2000-06-30 18:14:21 +02:00
|
|
|
<synopsis>
|
2003-03-13 02:30:29 +01:00
|
|
|
CREATE DATABASE <replaceable>name</>;
|
2000-06-30 18:14:21 +02:00
|
|
|
</synopsis>
|
2002-11-15 04:11:18 +01:00
|
|
|
where <replaceable>name</> follows the usual rules for
|
|
|
|
<acronym>SQL</acronym> identifiers. The current user automatically
|
|
|
|
becomes the owner of the new database. It is the privilege of the
|
|
|
|
owner of a database to remove it later on (which also removes all
|
|
|
|
the objects in it, even if they have a different owner).
|
1999-06-23 08:15:37 +02:00
|
|
|
</para>
|
|
|
|
|
2000-06-30 18:14:21 +02:00
|
|
|
<para>
|
|
|
|
The creation of databases is a restricted operation. See <xref
|
2001-11-18 01:38:00 +01:00
|
|
|
linkend="user-attributes"> for how to grant permission.
|
2000-06-30 18:14:21 +02:00
|
|
|
</para>
|
1999-06-23 08:15:37 +02:00
|
|
|
|
2002-09-25 23:16:10 +02:00
|
|
|
<para>
|
|
|
|
Since you need to be connected to the database server in order to
|
|
|
|
execute the <command>CREATE DATABASE</command> command, the
|
|
|
|
question remains how the <emphasis>first</> database at any given
|
|
|
|
site can be created. The first database is always created by the
|
|
|
|
<command>initdb</> command when the data storage area is
|
2003-08-31 19:32:24 +02:00
|
|
|
initialized. (See <xref linkend="creating-cluster">.) This
|
|
|
|
database is called
|
|
|
|
<literal>template1</>.<indexterm><primary>template1</></> So to
|
|
|
|
create the first <quote>real</> database you can connect to
|
2002-09-25 23:16:10 +02:00
|
|
|
<literal>template1</>.
|
|
|
|
</para>
|
1999-06-23 08:15:37 +02:00
|
|
|
|
2000-06-30 18:14:21 +02:00
|
|
|
<para>
|
2004-08-07 21:02:43 +02:00
|
|
|
The name <literal>template1</literal> is no accident: when a new
|
2000-06-30 18:14:21 +02:00
|
|
|
database is created, the template database is essentially cloned.
|
|
|
|
This means that any changes you make in <literal>template1</> are
|
|
|
|
propagated to all subsequently created databases. This implies that
|
|
|
|
you should not use the template database for real work, but when
|
2002-09-25 23:16:10 +02:00
|
|
|
used judiciously this feature can be convenient. More details
|
|
|
|
appear in <xref linkend="manage-ag-templatedbs">.
|
2000-06-30 18:14:21 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
As an extra convenience, there is also a program that you can
|
|
|
|
execute from the shell to create new databases,
|
2003-08-31 19:32:24 +02:00
|
|
|
<command>createdb</>.<indexterm><primary>createdb</></>
|
2000-06-30 18:14:21 +02:00
|
|
|
|
|
|
|
<synopsis>
|
|
|
|
createdb <replaceable class="parameter">dbname</replaceable>
|
|
|
|
</synopsis>
|
|
|
|
|
2003-03-13 02:30:29 +01:00
|
|
|
<command>createdb</> does no magic. It connects to the <literal>template1</>
|
2001-11-18 01:38:00 +01:00
|
|
|
database and issues the <command>CREATE DATABASE</> command,
|
2003-03-18 23:19:47 +01:00
|
|
|
exactly as described above.
|
|
|
|
The reference page on <command>createdb</> contains the invocation
|
2001-11-18 01:38:00 +01:00
|
|
|
details. Note that <command>createdb</> without any arguments will create
|
2000-06-30 18:14:21 +02:00
|
|
|
a database with the current user name, which may or may not be what
|
|
|
|
you want.
|
|
|
|
</para>
|
|
|
|
|
2002-09-25 23:16:10 +02:00
|
|
|
<note>
|
|
|
|
<para>
|
|
|
|
<xref linkend="client-authentication"> contains information about
|
|
|
|
how to restrict who can connect to a given database.
|
|
|
|
</para>
|
|
|
|
</note>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
Sometimes you want to create a database for someone else. That
|
|
|
|
user should become the owner of the new database, so he can
|
|
|
|
configure and manage it himself. To achieve that, use one of the
|
|
|
|
following commands:
|
|
|
|
<programlisting>
|
|
|
|
CREATE DATABASE <replaceable>dbname</> OWNER <replaceable>username</>;
|
|
|
|
</programlisting>
|
|
|
|
from the SQL environment, or
|
|
|
|
<programlisting>
|
|
|
|
createdb -O <replaceable>username</> <replaceable>dbname</>
|
|
|
|
</programlisting>
|
|
|
|
You must be a superuser to be allowed to create a database for
|
|
|
|
someone else.
|
|
|
|
</para>
|
|
|
|
</sect1>
|
|
|
|
|
|
|
|
<sect1 id="manage-ag-templatedbs">
|
|
|
|
<title>Template Databases</title>
|
2001-11-18 01:38:00 +01:00
|
|
|
|
|
|
|
<para>
|
|
|
|
<command>CREATE DATABASE</> actually works by copying an existing
|
|
|
|
database. By default, it copies the standard system database named
|
2003-08-31 19:32:24 +02:00
|
|
|
<literal>template1</>.<indexterm><primary>template1</></> Thus that
|
|
|
|
database is the <quote>template</> from which new databases are
|
|
|
|
made. If you add objects to <literal>template1</>, these objects
|
2001-11-18 01:38:00 +01:00
|
|
|
will be copied into subsequently created user databases. This
|
|
|
|
behavior allows site-local modifications to the standard set of
|
|
|
|
objects in databases. For example, if you install the procedural
|
2002-09-25 23:16:10 +02:00
|
|
|
language <application>PL/pgSQL</> in <literal>template1</>, it will
|
2003-08-31 19:32:24 +02:00
|
|
|
automatically be available in user databases without any extra
|
|
|
|
action being taken when those databases are made.
|
2001-11-18 01:38:00 +01:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2003-08-31 19:32:24 +02:00
|
|
|
There is a second standard system database named
|
|
|
|
<literal>template0</>.<indexterm><primary>template0</></> This
|
|
|
|
database contains the same data as the initial contents of
|
|
|
|
<literal>template1</>, that is, only the standard objects
|
|
|
|
predefined by your version of
|
|
|
|
<productname>PostgreSQL</productname>. <literal>template0</>
|
|
|
|
should never be changed after <command>initdb</>. By instructing
|
|
|
|
<command>CREATE DATABASE</> to copy <literal>template0</> instead
|
|
|
|
of <literal>template1</>, you can create a <quote>virgin</> user
|
|
|
|
database that contains none of the site-local additions in
|
|
|
|
<literal>template1</>. This is particularly handy when restoring a
|
|
|
|
<literal>pg_dump</> dump: the dump script should be restored in a
|
|
|
|
virgin database to ensure that one recreates the correct contents
|
|
|
|
of the dumped database, without any conflicts with additions that
|
|
|
|
may now be present in <literal>template1</>.
|
2001-11-18 01:38:00 +01:00
|
|
|
</para>
|
|
|
|
|
2002-09-25 23:16:10 +02:00
|
|
|
<para>
|
|
|
|
To create a database by copying <literal>template0</literal>, use
|
|
|
|
<programlisting>
|
|
|
|
CREATE DATABASE <replaceable>dbname</> TEMPLATE template0;
|
|
|
|
</programlisting>
|
|
|
|
from the SQL environment, or
|
|
|
|
<programlisting>
|
|
|
|
createdb -T template0 <replaceable>dbname</>
|
|
|
|
</programlisting>
|
|
|
|
from the shell.
|
|
|
|
</para>
|
|
|
|
|
2001-11-18 01:38:00 +01:00
|
|
|
<para>
|
|
|
|
It is possible to create additional template databases, and indeed
|
2003-03-13 02:30:29 +01:00
|
|
|
one might copy any database in a cluster by specifying its name
|
2001-11-18 01:38:00 +01:00
|
|
|
as the template for <command>CREATE DATABASE</>. It is important to
|
|
|
|
understand, however, that this is not (yet) intended as
|
2002-09-25 23:16:10 +02:00
|
|
|
a general-purpose <quote><command>COPY DATABASE</command></quote> facility. In particular, it is
|
2001-11-18 01:38:00 +01:00
|
|
|
essential that the source database be idle (no data-altering transactions
|
|
|
|
in progress)
|
|
|
|
for the duration of the copying operation. <command>CREATE DATABASE</>
|
|
|
|
will check
|
2003-03-13 02:30:29 +01:00
|
|
|
that no session (other than itself) is connected to
|
2001-11-18 01:38:00 +01:00
|
|
|
the source database at the start of the operation, but this does not
|
|
|
|
guarantee that changes cannot be made while the copy proceeds, which
|
|
|
|
would result in an inconsistent copied database. Therefore,
|
|
|
|
we recommend that databases used as templates be treated as read-only.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2003-08-31 19:32:24 +02:00
|
|
|
Two useful flags exist in <literal>pg_database</literal><indexterm><primary>pg_database</></> for each
|
2002-09-25 23:16:10 +02:00
|
|
|
database: the columns <literal>datistemplate</literal> and
|
2001-11-18 01:38:00 +01:00
|
|
|
<literal>datallowconn</literal>. <literal>datistemplate</literal>
|
|
|
|
may be set to indicate that a database is intended as a template for
|
|
|
|
<command>CREATE DATABASE</>. If this flag is set, the database may be
|
|
|
|
cloned by
|
2001-11-28 21:49:10 +01:00
|
|
|
any user with <literal>CREATEDB</> privileges; if it is not set, only superusers
|
2001-11-18 01:38:00 +01:00
|
|
|
and the owner of the database may clone it.
|
|
|
|
If <literal>datallowconn</literal> is false, then no new connections
|
|
|
|
to that database will be allowed (but existing sessions are not killed
|
|
|
|
simply by setting the flag false). The <literal>template0</literal>
|
2003-03-13 02:30:29 +01:00
|
|
|
database is normally marked <literal>datallowconn = false</> to prevent modification of it.
|
2001-11-18 01:38:00 +01:00
|
|
|
Both <literal>template0</literal> and <literal>template1</literal>
|
2003-03-13 02:30:29 +01:00
|
|
|
should always be marked with <literal>datistemplate = true</>.
|
2001-11-18 01:38:00 +01:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
After preparing a template database, or making any changes to one,
|
|
|
|
it is a good idea to perform
|
|
|
|
<command>VACUUM FREEZE</> or <command>VACUUM FULL FREEZE</> in that
|
|
|
|
database. If this is done when there are no other open transactions
|
2003-03-13 02:30:29 +01:00
|
|
|
in the same database, then it is guaranteed that all rows in the
|
2001-11-18 01:38:00 +01:00
|
|
|
database are <quote>frozen</> and will not be subject to transaction
|
|
|
|
ID wraparound problems. This is particularly important for a database
|
|
|
|
that will have <literal>datallowconn</literal> set to false, since it
|
2003-03-13 02:30:29 +01:00
|
|
|
will be impossible to do routine maintenance <command>VACUUM</> in
|
2001-11-18 01:38:00 +01:00
|
|
|
such a database.
|
|
|
|
See <xref linkend="vacuum-for-wraparound"> for more information.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<note>
|
|
|
|
<para>
|
|
|
|
<literal>template1</> and <literal>template0</> do not have any special
|
|
|
|
status beyond the fact that the name <literal>template1</> is the default
|
|
|
|
source database name for <command>CREATE DATABASE</> and the default
|
2002-09-25 23:16:10 +02:00
|
|
|
database-to-connect-to for various programs such as <command>createdb</>.
|
2001-11-18 01:38:00 +01:00
|
|
|
For example, one could drop <literal>template1</> and recreate it from
|
|
|
|
<literal>template0</> without any ill effects. This course of action
|
|
|
|
might be advisable if one has carelessly added a bunch of junk in
|
|
|
|
<literal>template1</>.
|
|
|
|
</para>
|
|
|
|
</note>
|
2002-09-25 23:16:10 +02:00
|
|
|
</sect1>
|
|
|
|
|
|
|
|
<sect1 id="manage-ag-config">
|
|
|
|
<title>Database Configuration</title>
|
|
|
|
|
|
|
|
<para>
|
2002-11-15 04:11:18 +01:00
|
|
|
Recall from <xref linkend="runtime-config"> that the
|
|
|
|
<productname>PostgreSQL</> server provides a large number of
|
|
|
|
run-time configuration variables. You can set database-specific
|
|
|
|
default values for many of these settings.
|
2002-09-25 23:16:10 +02:00
|
|
|
</para>
|
2001-11-18 01:38:00 +01:00
|
|
|
|
2002-09-25 23:16:10 +02:00
|
|
|
<para>
|
|
|
|
For example, if for some reason you want to disable the
|
|
|
|
<acronym>GEQO</acronym> optimizer for a given database, you'd
|
|
|
|
ordinarily have to either disable it for all databases or make sure
|
|
|
|
that every connecting client is careful to issue <literal>SET geqo
|
2004-08-07 21:02:43 +02:00
|
|
|
TO off;</literal>. To make this setting the default within a particular
|
|
|
|
database, you can execute the command
|
2002-09-25 23:16:10 +02:00
|
|
|
<programlisting>
|
|
|
|
ALTER DATABASE mydb SET geqo TO off;
|
|
|
|
</programlisting>
|
|
|
|
This will save the setting (but not set it immediately) and in
|
|
|
|
subsequent connections it will appear as though <literal>SET geqo
|
|
|
|
TO off;</literal> had been called right before the session started.
|
|
|
|
Note that users can still alter this setting during the session; it
|
|
|
|
will only be the default. To undo any such setting, use
|
|
|
|
<literal>ALTER DATABASE <replaceable>dbname</> RESET
|
|
|
|
<replaceable>varname</>;</literal>.
|
|
|
|
</para>
|
|
|
|
</sect1>
|
2001-11-18 01:38:00 +01:00
|
|
|
|
2000-09-29 22:21:34 +02:00
|
|
|
<sect1 id="manage-ag-dropdb">
|
2000-06-30 18:14:21 +02:00
|
|
|
<title>Destroying a Database</title>
|
1999-06-23 08:15:37 +02:00
|
|
|
|
2000-06-30 18:14:21 +02:00
|
|
|
<para>
|
2004-08-07 21:02:43 +02:00
|
|
|
Databases are destroyed with the command
|
2004-08-07 21:14:45 +02:00
|
|
|
<xref linkend="sql-dropdatabase">:<indexterm><primary>DROP DATABASE</></>
|
2000-06-30 18:14:21 +02:00
|
|
|
<synopsis>
|
2003-03-13 02:30:29 +01:00
|
|
|
DROP DATABASE <replaceable>name</>;
|
2000-06-30 18:14:21 +02:00
|
|
|
</synopsis>
|
2004-08-07 21:02:43 +02:00
|
|
|
Only the owner of the database (i.e., the user that created it), or
|
2001-11-18 01:38:00 +01:00
|
|
|
a superuser, can drop a database. Dropping a database removes all objects
|
|
|
|
that were
|
2000-06-30 18:14:21 +02:00
|
|
|
contained within the database. The destruction of a database cannot
|
|
|
|
be undone.
|
|
|
|
</para>
|
1999-06-23 08:15:37 +02:00
|
|
|
|
2000-06-30 18:14:21 +02:00
|
|
|
<para>
|
|
|
|
You cannot execute the <command>DROP DATABASE</command> command
|
|
|
|
while connected to the victim database. You can, however, be
|
2001-11-18 01:38:00 +01:00
|
|
|
connected to any other database, including the <literal>template1</>
|
2003-03-13 02:30:29 +01:00
|
|
|
database.
|
|
|
|
<literal>template1</> would be the only option for dropping the last user database of a
|
2000-06-30 18:14:21 +02:00
|
|
|
given cluster.
|
|
|
|
</para>
|
1999-06-23 08:15:37 +02:00
|
|
|
|
2000-06-30 18:14:21 +02:00
|
|
|
<para>
|
2003-08-31 19:32:24 +02:00
|
|
|
For convenience, there is also a shell program to drop
|
|
|
|
databases:<indexterm><primary>dropdb</></>
|
2000-06-30 18:14:21 +02:00
|
|
|
<synopsis>
|
|
|
|
dropdb <replaceable class="parameter">dbname</replaceable>
|
|
|
|
</synopsis>
|
|
|
|
(Unlike <command>createdb</>, it is not the default action to drop
|
|
|
|
the database with the current user name.)
|
|
|
|
</para>
|
|
|
|
</sect1>
|
2004-06-21 06:06:07 +02:00
|
|
|
|
|
|
|
<sect1 id="manage-ag-tablespaces">
|
|
|
|
<title>Tablespaces</title>
|
|
|
|
|
2004-09-30 04:40:23 +02:00
|
|
|
<indexterm zone="manage-ag-tablespaces">
|
|
|
|
<primary>tablespace</primary>
|
|
|
|
</indexterm>
|
|
|
|
|
2004-06-21 06:06:07 +02:00
|
|
|
<para>
|
2004-08-07 21:02:43 +02:00
|
|
|
Tablespaces in <productname>PostgreSQL</> allow database administrators to
|
2004-06-21 06:06:07 +02:00
|
|
|
define locations in the file system where the files representing
|
|
|
|
database objects can be stored. Once created, a tablespace can be referred
|
|
|
|
to by name when creating database objects.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2004-10-29 04:11:18 +02:00
|
|
|
By using tablespaces, an administrator can control the disk layout
|
|
|
|
of a <productname>PostgreSQL</> installation. This is useful in at
|
|
|
|
least two ways. First, if the partition or volume on which the
|
|
|
|
cluster was initialized runs out of space and cannot be extended,
|
|
|
|
a tablespace can be created on a different partition and used
|
|
|
|
until the system can be reconfigured.
|
2004-06-21 06:06:07 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2004-10-29 04:11:18 +02:00
|
|
|
Second, tablespaces allow an administrator to use knowledge of the
|
|
|
|
usage pattern of database objects to optimize performance. For
|
|
|
|
example, an index which is very heavily used can be placed on a
|
|
|
|
very fast, highly available disk, such as an expensive solid state
|
|
|
|
device. At the same time a table storing archived data which is
|
|
|
|
rarely used or not performance critical could be stored on a less
|
|
|
|
expensive, slower disk system.
|
2004-06-21 06:06:07 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2004-08-07 21:14:45 +02:00
|
|
|
To define a tablespace, use the <xref linkend="sql-createtablespace">
|
|
|
|
command, for example:<indexterm><primary>CREATE TABLESPACE</></>
|
2004-08-07 21:02:43 +02:00
|
|
|
<programlisting>
|
|
|
|
CREATE TABLESPACE fastspace LOCATION '/mnt/sda1/postgresql/data';
|
|
|
|
</programlisting>
|
|
|
|
The location must be an existing, empty directory that is owned by
|
|
|
|
the <productname>PostgreSQL</> system user. All objects subsequently
|
|
|
|
created within the tablespace will be stored in files underneath this
|
|
|
|
directory.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<note>
|
2004-10-29 04:11:18 +02:00
|
|
|
<para>
|
|
|
|
There is usually not much point in making more than one
|
|
|
|
tablespace per logical filesystem, since you cannot control the location
|
|
|
|
of individual files within a logical filesystem. However,
|
|
|
|
<productname>PostgreSQL</> does not enforce any such limitation, and
|
|
|
|
indeed it is not directly aware of the filesystem boundaries on your
|
|
|
|
system. It just stores files in the directories you tell it to use.
|
|
|
|
</para>
|
2004-08-07 21:02:43 +02:00
|
|
|
</note>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
Creation of the tablespace itself must be done as a database superuser,
|
|
|
|
but after that you can allow ordinary database users to make use of it.
|
|
|
|
To do that, grant them the <literal>CREATE</> privilege on it.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2004-11-05 20:17:13 +01:00
|
|
|
Tables, indexes, and entire databases can be assigned to
|
2004-06-21 06:06:07 +02:00
|
|
|
particular tablespaces. To do so, a user with the <literal>CREATE</>
|
|
|
|
privilege on a given tablespace must pass the tablespace name as a
|
|
|
|
parameter to the relevant command. For example, the following creates
|
|
|
|
a table in the tablespace <literal>space1</>:
|
|
|
|
<programlisting>
|
|
|
|
CREATE TABLE foo(i int) TABLESPACE space1;
|
|
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2004-11-05 20:17:13 +01:00
|
|
|
Alternatively, use the <xref linkend="guc-default-tablespace"> parameter:
|
|
|
|
<programlisting>
|
|
|
|
SET default_tablespace = space1;
|
|
|
|
CREATE TABLE foo(i int);
|
|
|
|
</programlisting>
|
|
|
|
When <varname>default_tablespace</> is set to anything but an empty
|
|
|
|
string, it supplies an implicit <literal>TABLESPACE</> clause for
|
|
|
|
<command>CREATE TABLE</> and <command>CREATE INDEX</> commands that
|
|
|
|
do not have an explicit one.
|
2004-06-21 06:06:07 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2004-11-05 20:17:13 +01:00
|
|
|
The tablespace associated with a database is used to store the system
|
|
|
|
catalogs of that database, as well as any temporary files created by
|
|
|
|
server processes using that database. Furthermore, it is the default
|
|
|
|
tablespace selected for tables and indexes created within the database,
|
|
|
|
if no <literal>TABLESPACE</> clause is given (either explicitly or via
|
|
|
|
<varname>default_tablespace</>) when the objects are created.
|
|
|
|
If a database is created without specifying a tablespace for it,
|
|
|
|
it uses the same tablespace as the template database it is copied from.
|
2004-06-21 06:06:07 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
Two tablespaces are automatically created by <literal>initdb</>. The
|
|
|
|
<literal>pg_global</> tablespace is used for shared system catalogs. The
|
|
|
|
<literal>pg_default</> tablespace is the default tablespace of the
|
|
|
|
<literal>template1</> and <literal>template0</> databases (and, therefore,
|
2004-11-05 20:17:13 +01:00
|
|
|
will be the default tablespace for other databases as well, unless
|
|
|
|
overridden by a <literal>TABLESPACE</> clause in <command>CREATE
|
|
|
|
DATABASE</>).
|
2004-06-21 06:06:07 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
Once created, a tablespace can be used from any database, provided
|
|
|
|
the requesting user has sufficient privilege. This means that a tablespace
|
|
|
|
cannot be dropped until all objects in all databases using the tablespace
|
|
|
|
have been removed.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
To simplify the implementation of tablespaces,
|
|
|
|
<productname>PostgreSQL</> makes extensive use of symbolic links. This
|
|
|
|
means that tablespaces can be used <emphasis>only</> on systems
|
|
|
|
that support symbolic links.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
The directory <filename>$PGDATA/pg_tblspc</> contains symbolic links that
|
|
|
|
point to each of the non-built-in tablespaces defined in the cluster.
|
|
|
|
Although not recommended, it is possible to adjust the tablespace
|
|
|
|
layout by hand by redefining these links. Two warnings: do not do so
|
|
|
|
while the postmaster is running; and after you restart the postmaster,
|
|
|
|
update the <structname>pg_tablespace</> catalog to show the new
|
|
|
|
locations. (If you do not, <literal>pg_dump</> will continue to show
|
|
|
|
the old tablespace locations.)
|
|
|
|
</para>
|
|
|
|
|
|
|
|
</sect1>
|
1999-06-23 08:15:37 +02:00
|
|
|
</chapter>
|
|
|
|
|
|
|
|
<!-- Keep this comment at the end of the file
|
|
|
|
Local variables:
|
2000-03-31 05:27:42 +02:00
|
|
|
mode:sgml
|
1999-06-23 08:15:37 +02:00
|
|
|
sgml-omittag:nil
|
|
|
|
sgml-shorttag:t
|
|
|
|
sgml-minimize-attributes:nil
|
|
|
|
sgml-always-quote-attributes:t
|
|
|
|
sgml-indent-step:1
|
|
|
|
sgml-indent-data:t
|
|
|
|
sgml-parent-document:nil
|
|
|
|
sgml-default-dtd-file:"./reference.ced"
|
|
|
|
sgml-exposed-tags:nil
|
2000-03-31 05:27:42 +02:00
|
|
|
sgml-local-catalogs:("/usr/lib/sgml/catalog")
|
1999-06-23 08:15:37 +02:00
|
|
|
sgml-local-ecat-files:nil
|
|
|
|
End:
|
|
|
|
-->
|