データベースにアクセスするためには、まずデータベースサーバを起動しなくてはいけません。
データベースサーバプログラムはpostgresという名前です。
パッケージ化された版のPostgreSQLを使用している場合は、オペレーティングシステムの規則に従って、サーバをバックグラウンドタスクとして実行するための提供がほぼ確実に含まれています。 パッケージの基盤を使用してサーバを起動させるほうが、自分でこれをおこなう方法を理解するよりもはるかに作業量が少なくなります。 詳細についてはパッケージレベルのドキュメントを参照してください。
サーバを手動で起動するための必要最低限の方法は、-Dオプションを使用してデータディレクトリの場所を指定postgresを直接呼び出することです。
次に例を示します。
$ postgres -D /usr/local/pgsql/data
上記のコマンドはサーバをフォアグラウンドで実行させます。
これは、PostgreSQLユーザアカウントでログインしている間に実行されなくてはいけません。
-Dオプションが指定されていない場合、サーバはPGDATA環境変数で指定されたデータディレクトリを使用しようと試みます。
どちらの変数も指定されていなければ失敗します。
通常はバックグラウンドでpostgresを起動することをお勧めします。
そのためには以下のように通常のUnixシェルの構文を使います。
$ postgres -D /usr/local/pgsql/data >logfile 2>&1 &
この例のように、サーバの標準出力と標準エラー出力をどこかに保管しておくことが重要です。 これは監査目的と問題の原因究明に役立ちます。 （ログファイルの取り扱いについての全体的な説明については25.3を参照してください。）
postgresプログラムには、この他にも多くのコマンドラインオプションを指定することができます。
詳細はpostgresマニュアルページと後述の第20章を参照してください。
こうしたシェル構文は長くなりがちです。そのため、 pg_ctl ラッパープログラムが提供されていて、いくつかのタスクを単純化しています。 以下に例を示します。
pg_ctl start -l logfile
これは、サーバをバックグラウンドで起動し、出力を指定されたログファイルに書き出します。
-Dオプションは、ここでもpostgresの場合と同じ意味を持ちます。
pg_ctlによってサーバを停止させることもできます。
通常、コンピュータが起動された時にデータベースサーバも一緒に起動したい場合が多いと思われます。
自動起動スクリプトはオペレーティングシステム固有のものです。
いくつかのスクリプトの例はPostgreSQLのcontrib/start-scriptsディレクトリに同梱されています。
このインストールにはおそらくroot権限が必要となります。
起動時にデーモンを開始する方法はシステムによって異なります。
多くのシステムには/etc/rc.localファイルや/etc/rc.d/rc.localファイルがあります。
他のシステムではinit.dやrc.dディレクトリが使用されます。
何を実行するにしても、サーバはPostgreSQLユーザアカウントで起動させなければなりません。
rootであってはいけませんし、他のユーザでもいけません。
したがって、su postgres -c '...'を使用してコマンドを実行する必要があるでしょう。
以下に例を示します。
su postgres -c 'pg_ctl start -D /usr/local/pgsql/data -l serverlog'
さらにいくつかのオペレーティングシステム固有の提案を挙げます。 （ここでは一般的な値で説明していますので、各項目において適切なインストールディレクトリとユーザ名に置き換えて読んでください。）
FreeBSDでは、PostgreSQLのソース配布物の中にあるcontrib/start-scripts/freebsdファイルを参照してください。
OpenBSDでは、以下の数行を/etc/rc.localファイルに追加してください。
if [ -x /usr/local/pgsql/bin/pg_ctl -a -x /usr/local/pgsql/bin/postgres ]; then
su -l postgres -c '/usr/local/pgsql/bin/pg_ctl start -s -l /var/postgresql/log -D /usr/local/pgsql/data'
echo -n ' postgresql'
fi
/usr/local/pgsql/bin/pg_ctl start -l logfile -D /usr/local/pgsql/data
を/etc/rc.d/rc.localや/etc/rc.localに追加してください。
または、PostgreSQLのソース配布物の中にあるcontrib/start-scripts/linuxファイルを参照してください。
systemdを使用する場合は以下のサービスユニットファイルを（例えば/etc/systemd/system/postgresql.serviceとして）使用できます。
[Unit] Description=PostgreSQL database server Documentation=man:postgres(1) After=network-online.target Wants=network-online.target [Service] Type=notify User=postgres ExecStart=/usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data ExecReload=/bin/kill -HUP $MAINPID KillMode=mixed KillSignal=SIGINT TimeoutSec=infinity [Install] WantedBy=multi-user.target
Type=notifyを使うには、サーバのバイナリがconfigure --with-systemdでビルドされている必要があります。
タイムアウトの設定について慎重に検討してください。
この文書を書いている時点で、systemdのデフォルトのタイムアウトは90秒で、その時間内に準備ができたことを報告しないプロセスは終了させられます。
しかし、PostgreSQLサーバは起動時にクラッシュリカバリを実行せねばならないことがあり、準備ができるまでにそれよりずっと長い時間を要することがあります。
ここで提案されているinfinityという値は、そのタイムアウトの仕組みを無効にします。
Solarisでは、/etc/init.d/postgresqlというファイルを作成し、そこに以下の1行を記述してください。
su - postgres -c "/usr/local/pgsql/bin/pg_ctl start -l logfile -D /usr/local/pgsql/data"
そして、/etc/rc3.d以下にS99postgresqlとしてそのファイルに対するシンボリックリンクを作成してください。
サーバが実行している間は、そのPIDはデータディレクトリの中のpostmaster.pidファイルに記述されています。
これは同じデータディレクトリで複数のサーバインスタンスが実行されるのを防止し、また、サーバの停止にも使うことができます。
サーバの起動が失敗する理由として代表的なものがいくつかあります。 サーバのログファイルを点検するか、（標準出力や標準エラーをリダイレクトせずに）手動で起動して、どのようなエラーメッセージが出ているか確認してください。 以下に、よく発生するエラーメッセージのいくつかをより詳細に説明します。
LOG: could not bind IPv4 address "127.0.0.1": Address already in use HINT: Is another postmaster already running on port 5432? If not, wait a few seconds and retry. FATAL: could not create any TCP/IP sockets
これはたいていの場合メッセージが示す通りの意味です。
既にサーバが動いているポートで別のサーバを起動しようとしたことを示しています。
しかし、カーネルエラーメッセージがAddress already in useやそれに類似したものではない場合は、別の問題の可能性もあります。
例えば、予約済みのポート番号でサーバを起動しようとすると下記のようなメッセージが出るかもしれません。
$ postgres -p 666
LOG: could not bind IPv4 address "127.0.0.1": Permission denied
HINT: Is another postmaster already running on port 666? If not, wait a few seconds and retry.
FATAL: could not create any TCP/IP sockets
次のようなメッセージが表示された場合、
FATAL: could not create shared memory segment: Invalid argument DETAIL: Failed system call was shmget(key=5440001, size=4011376640, 03600).
これは、おそらくカーネルによる共有メモリのサイズの上限がPostgreSQLが作ろうとしている作業領域（この例では4011376640バイト）よりも小さいことを示しています。
これはshared_memory_typeをsysvに設定した場合にのみ発生する可能性があります。
その場合は、サーバを通常よりも少ないバッファ数（shared_buffers）で起動するか、カーネルを再設定して許容される共有メモリサイズを増やすこともできます。
このメッセージは、同じマシン上で複数のサーバを起動しようとした時に、要求された領域の合計がカーネルの上限を超えた場合にも表示されます。
下記のようなエラーの場合:
FATAL: could not create semaphores: No space left on device DETAIL: Failed system call was semget(5440126, 17, 03600).
ディスクの空き容量がなくなったということを示しているわけではありません。 これはカーネルのSystem Vセマフォの上限が、PostgreSQLが作成しようとしている数よりも小さいということを意味しています。 上記のように、許可される接続の数（max_connections）を減らしてサーバを起動させることで問題は回避できるかもしれませんが、最終的にはカーネルの設定を変えてセマフォの上限を増やした方が良いでしょう。
System V IPC設備の設定についての詳細は19.4.1を参照してください。
クライアント側で起こり得るエラー状態はきわめて多様で、アプリケーションに依存します。 その中のいくつかはサーバが起動された方法と直接関係するかもしれません。 以下で説明する以外の状態については各々のクライアントアプリケーションの資料を参照してください。
psql: error: connection to server at "server.joe.com" (123.123.123.123), port 5432 failed: Connection refused
Is the server running on that host and accepting TCP/IP connections?
これは一般的な「接続するサーバが見つけられませんでした」という失敗です。 TCP/IP通信を試みた時に上記のように表示されます。 よくある間違いはサーバにTCP/IPを許可する設定を忘れていることです。
代わりに、ローカルのサーバにUnixソケット通信を試みると下記のような表示が出ます。
psql: error: connection to server on socket "/tmp/.s.PGSQL.5432" failed: No such file or directory
Is the server running locally and accepting connections on that socket?
サーバが実行中にもかかわらずこうなるなら、クライアントが想定しているソケットパス（ここでは/tmp）がサーバのunix_socket_directories設定と一致しているかどうか確認してください。
接続失敗のメッセージは常にサーバのアドレスか、ソケットパス名を表示し、クライアントが正しいところに接続しようとしていることを確認するのに役立ちます。
もしそこを接続待ちしているサーバがない場合、典型的なカーネルエラーメッセージは、表示されているようにConnection refusedもしくはNo such file or directoryとなります。
（この場合のConnection refusedはサーバが接続要求を受け付けた後に拒否したわけではないということを理解しておくことが大切です。
もしそうだった場合は21.15で示されるような別のメッセージが表示されます。）
Connection timed outのような他のメッセージは、例えばネットワーク接続の欠如、あるいはファイアーウォールが接続をブロックしているようなもっと根本的な問題を表しています。