mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-07-16 04:21:11 +02:00
a2405d5554
initdb -t. This option is obsoleted by 7.1's ability to drop and recreate template1 during normal operation.
233 lines
7.5 KiB
Plaintext
233 lines
7.5 KiB
Plaintext
<!--
|
|
$Header: /cvsroot/pgsql/doc/src/sgml/ref/initdb.sgml,v 1.15 2001/01/20 22:09:24 tgl Exp $
|
|
Postgres documentation
|
|
-->
|
|
|
|
<refentry id="APP-INITDB">
|
|
<docinfo>
|
|
<date>2000-12-25</date>
|
|
</docinfo>
|
|
|
|
<refmeta>
|
|
<refentrytitle id="APP-INITDB-TITLE"><application>initdb</application></refentrytitle>
|
|
<manvolnum>1</manvolnum>
|
|
<refmiscinfo>Application</refmiscinfo>
|
|
</refmeta>
|
|
|
|
<refnamediv>
|
|
<refname>initdb</refname>
|
|
<refpurpose>Create a new <productname>Postgres</productname> database cluster</refpurpose>
|
|
</refnamediv>
|
|
|
|
<refsynopsisdiv>
|
|
<cmdsynopsis>
|
|
<command>initdb</command>
|
|
<group choice="plain">
|
|
<arg>--pgdata </arg>
|
|
<arg>-D </arg>
|
|
<replaceable>dbdir</replaceable>
|
|
</group>
|
|
<group>
|
|
<arg>--sysid </arg>
|
|
<arg>-i </arg>
|
|
<replaceable>sysid</replaceable>
|
|
</group>
|
|
<group><arg>--pwprompt</arg><arg>-W</arg></group>
|
|
<group>
|
|
<arg>--encoding </arg>
|
|
<arg>-E </arg>
|
|
<replaceable>encoding</replaceable>
|
|
</group>
|
|
<arg>-L <replaceable>directory</replaceable></arg>
|
|
<group><arg>--noclean</arg><arg>-n</arg></group>
|
|
<group><arg>--debug</arg><arg>-d</arg></group>
|
|
</cmdsynopsis>
|
|
</refsynopsisdiv>
|
|
|
|
<refsect1 id="R1-APP-INITDB-1">
|
|
<title>
|
|
Description
|
|
</title>
|
|
<para>
|
|
<application>initdb</application> creates a new
|
|
<productname>Postgres</productname> database cluster or system. A
|
|
database cluster is a collection of databases that are managed by a
|
|
single postmaster.
|
|
</para>
|
|
<para>
|
|
Creating a database system consists of creating the directories in which
|
|
the database data will live, generating the shared catalog tables
|
|
(tables that belong to the whole cluster rather than to any particular
|
|
database), and creating the <literal>template1</literal>
|
|
database. When you create a new database, everything in the
|
|
<literal>template1</literal> database is copied.
|
|
It contains catalog tables filled in for things like the
|
|
built-in types.
|
|
</para>
|
|
|
|
<para>
|
|
You must not execute <application>initdb</application> as root; it must
|
|
be run by the Unix user account that will run the database server.
|
|
This is because you cannot run the database server as root either, but the
|
|
server needs to have access to the files <application>initdb</application>
|
|
creates. Furthermore, during the initialization phase, when there are no
|
|
users and no access controls installed, <productname>Postgres</productname>
|
|
will only connect with
|
|
the name of the current Unix user, so you must log in under the account
|
|
that will own the server process.
|
|
</para>
|
|
|
|
<para>
|
|
Although <application>initdb</application> will attempt to create the
|
|
specified data directory, often it won't have permission to do so,
|
|
since the parent of the desired data directory is often a root-owned
|
|
directory. To set up an arrangement like this, create an empty data
|
|
directory as root, then use <application>chown</application> to hand over
|
|
ownership of that directory to the database user account, then
|
|
<application>su</application> to become the database user, and
|
|
finally run <application>initdb</application> as the database user.
|
|
</para>
|
|
|
|
<refsect2>
|
|
<title>Options</title>
|
|
|
|
<para>
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term>--pgdata=<replaceable class="parameter">dbdir</replaceable></term>
|
|
<term>-D <replaceable class="parameter">dbdir</replaceable></term>
|
|
<listitem>
|
|
<para>
|
|
This option specifies where in the file system the database
|
|
should be stored. This is the only information required by
|
|
<application>initdb</application>, but you can avoid writing it by
|
|
setting the <envar>PGDATA</envar> environment variable, which
|
|
can be convenient since the database server
|
|
(<filename>postmaster</filename>) can find the database
|
|
directory later by the same variable.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>--sysid=<replaceable class="parameter">sysid</replaceable></term>
|
|
<term>-i <replaceable class="parameter">sysid</replaceable></term>
|
|
<listitem>
|
|
<para>
|
|
Selects the system id of the database superuser. This defaults
|
|
to the effective user id of the user running
|
|
<application>initdb</application>. It is really not important
|
|
what the superuser's sysid is, but one might choose to start
|
|
the numbering at some number like 1.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>--pwprompt</term>
|
|
<term>-W</term>
|
|
<listitem>
|
|
<para>
|
|
Makes <application>initdb</application> prompt for a password
|
|
to give the database superuser. If you don't plan on using password
|
|
authentication, this is not important. Otherwise you won't be
|
|
able to use password authentication until you have a password
|
|
set up.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>--encoding=<replaceable class="parameter">encoding</replaceable></term>
|
|
<term>-E <replaceable class="parameter">encoding</replaceable></term>
|
|
<listitem>
|
|
<para>
|
|
Selects the multibyte encoding of the template database. This will also
|
|
be the default encoding of any database you create later, unless you
|
|
override it there. To use the multibyte encoding feature, you must
|
|
specify so at build time, at which time you also select the default
|
|
for this option.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
</variablelist>
|
|
</para>
|
|
|
|
<para>
|
|
Other, less commonly used, parameters are also available:
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term>-L <replaceable class="parameter">directory</replaceable></term>
|
|
<listitem>
|
|
<para>
|
|
Specifies where <application>initdb</application> should find
|
|
its input files to initialize the database system. This is
|
|
normally not necessary. You will be told if you need to
|
|
specify their location explicitly.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>--noclean</term>
|
|
<term>-n</term>
|
|
<listitem>
|
|
<para>
|
|
By default, when <application>initdb</application>
|
|
determines that an error prevented it from completely creating the database
|
|
system, it removes any files it may have created before discovering
|
|
that it can't finish the job. This option inhibits tidying-up and is
|
|
thus useful for debugging.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>--debug</term>
|
|
<term>-d</term>
|
|
<listitem>
|
|
<para>
|
|
Print debugging output from the bootstrap backend and a few other
|
|
messages of lesser interest for the general public.
|
|
The bootstrap backend is the program <application>initdb</application>
|
|
uses to create the catalog tables. This option generates a tremendous
|
|
amount of extremely boring output.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
</variablelist>
|
|
</para>
|
|
|
|
</refsect2>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>See also</title>
|
|
|
|
<simpara>
|
|
<citetitle>PostgreSQL Administrator's Guide</citetitle>
|
|
</simpara>
|
|
</refsect1>
|
|
|
|
</refentry>
|
|
|
|
<!-- Keep this comment at the end of the file
|
|
Local variables:
|
|
mode: sgml
|
|
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
|
|
sgml-local-catalogs:"/usr/lib/sgml/catalog"
|
|
sgml-local-ecat-files:nil
|
|
End:
|
|
-->
|