データベースにアクセスするためには、まずデータベースサーバを起動しなくてはいけません。データベースサーバはpostmasterと呼ばれます。postmasterは自分が作業するデータがどこにあるのかを知っている必要があり、これはオプション-Dで指定できます。したがって、サーバを起動する一番簡単な方法例は、以下のようなコマンドとなります。
$ postmaster -D /usr/local/pgsql/data
上記のコマンドは、サーバをフォアグラウンドで実行させます。これもまた PostgreSQLユーザアカウントにログインして実行されなくてはいけません。-Dオプションが指定されていない場合、サーバは環境変数PGDATAで指定されたデータディレクトリを使用しようと試みます。両方の方法でもできない場合は失敗します。
バックグランドでpostmasterを起動するには以下のように通常のシェルの構文を使います。
$ postmaster -D /usr/local/pgsql/data > logfile 2>&1 &
この例のように、サーバーのstdoutと stderrをどこかに残しておくことを強くお勧めします。これは追跡記録的な役割と問題の原因究明の2つの役割があります(ログファイルの取り扱いについての全体的な説明については Section 8.3 を参照して下さい)。
postmasterには、このほかにも多くのコマンドラインオプションを指定することができます。詳しい情報はリファレンスページと後述の Section 3.4 を参照してください。特に、postmasterが（Unixドメインソケットではなく）TCP/IP接続を受け入れるためにはオプション -iを指定する必要があります。
このシェル構文はすぐに長くなります。したがってシェルスクリプトラッパであるpg_ctlコマンドが提供されていて、いくつかのタスクをカプセル化することができます。たとえば、以下のように使います。
pg_ctl start -l logfile
これは、サーバをバックグラウンドで起動し、出力を指定されたログファイルに書き出します。-Dオプションはpostmasterを直接呼び出す場合と同じ意味を持ちます。また、pg_ctlはpostmasterを起動するだけでなく、"stop"することもできます。
通常、コンピュータが起動されたときにデータベースサーバも一緒に起動する場合が多いと思われます。必ずしもそうする必要はありません。 PostgreSQLサーバは権限を持たないアカウントからでもrootの介入なしで起動させることができます。
ブート時にデーモンを開始する方法はシステムによって異なりますが、精通しておいたほうがよいでしょう。多くのシステムには/etc/rc.local ファイルや/etc/rc.d/rc.localファイルがあり、それらのコマンドを置いておくには適切な場所だといえます。何を実行するにしても、サーバは PostgreSQLユーザアカウントで起動させなければなりません。rootであってはいけませんし、他のユーザーでもいけません。したがって、su -c '...' postgresのような専用のコマンドを作っておいたほうがよいでしょう。たとえば次のようなものが考えられます。
su -c 'pg_ctl start -D /usr/local/pgsql/data -l serverlog' postgres
さらにいくつかのオペレーティングシステム固有の提案を挙げます（適切なインストールディレクトリと自分が選んだユーザー名に置き換えて読んでください）。
FreeBSDでは、 PostgreSQLで配布されるソースの中にある contrib/start-scripts/freebsdファイルを参照してください。
OpenBSDでは、以下の数行を /etc/rc.localファイルに追加してください。
if [ -x /usr/local/pgsql/bin/pg_ctl -a -x /usr/local/pgsql/bin/postmaster ]; then
su - -c '/usr/local/pgsql/bin/pg_ctl start -l /var/postgresql/log -s' postgres
echo -n ' postgresql'
fi
Linuxシステムでは、以下の行を /etc/rc.d/rc.localファイルに追加してください。
/usr/local/pgsql/bin/pg_ctl start -l logfile -D /usr/local/pgsql/data
または、PostgreSQLの配布されるソースの中にあるファイルcontrib/start-scripts/linuxの中から起動と終了をランレベルシステムと合わせる方法を探してください。
NetBSDでは FreeBSDかLinuxの好きな方の起動スクリプトを例として使い、 /usr/local/etc/rc.d/postgresqlに置いてください。
Solarisでは、 rc2.d/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 としてそのファイルに対するシンボリックリンクを作成して下さい
postmasterが実行している間は、その PIDはデータディレクトリの中の postmaster.pidファイルに記述されています。これは同じデータディレクトリで動く複数のpostmasterの調整をし、postmasterの終了にも使うことができます。
postmasterの起動が失敗する理由として、代表的なものがいくつかあります。postmasterのログファイルをチェックするか、どのようなエラーメッセージが出ているか見るには、（標準出力か標準エラーをリダイレクトせずに）手動で起動してみてください。いくつかのエラーメッセージは比較的原因がわかりやすいものですが、そうではないものについてここで説明します。
FATAL: StreamServerPort: bind() failed: Address already in use
Is another postmaster already running on that port?
これは多くの場合、すでにpostmasterが動いているポートで2つ目のpostmasterを起動しようとした可能性があることを示しています。しかし、もしカーネルエラーメッセージがAddress already in useではない場合や、それに似たようなものだった場合は別の問題の可能性もあります。たとえば、予約済みのポート番号でpostmasterを起動しようとすると下記のようなメッセージが出ます。
$ postmaster -i -p 666
FATAL: StreamServerPort: bind() failed: Permission denied
Is another postmaster already running on that port?
IpcMemoryCreate: shmget(key=5440001, size=83918612, 01600) failed: Invalid argument FATAL 1: ShmemCreate: cannot create region
上記のようなメッセージが出た場合は、おそらく共有メモリ領域のカーネルの上限が PostgreSQL が作ろうとしているバッファ領域よりも小さい可能性があります（この例では83,918,612バイトです）。または、System V方式の共有メモリサポートがカーネルにまったく設定されていない可能性もあります。一時的な策として、（-Bオプションを使用して）postmasterを通常よりも少ないバッファ数で起動することもできます。しかし最終的には、カーネルを再設定し、使用可能共有メモリサイズを増やしたほうがよいでしょう。このメッセージは、同じマシン上で複数のpostmasterを起動させようとするときに要求された空間の合計がカーネルの上限を越えた場合にも表示されます。
下記のようなエラーはディスクの空き容量がなくなったということを示しているわけではありません。
IpcSemaphoreCreate: semget(key=5440026, num=16, 01600) failed: No space left on device
これはカーネルのSystem Vセマフォの上限がPostgreSQL が作成しようとしている数よりも小さいということを意味しています。上記のように、バックエンドプロセス数を減らして（-Nオプションを使用して）postmasterを起動させることで問題は回避できるかもしれませんが、最終的にはカーネルの設定を変えてセマフォの上限を増やした方がよいでしょう。
"illegal system call"というエラーが表示された場合は、使用しているカーネルでは共有メモリやセマフォがまったくサポートされていない可能性があります。その場合、これらの機能を使えるようにカーネルを設定し直すことが唯一の選択肢となります。
System V IPC設備の設定についての詳細はSection 3.5.1を参照してください。
クライアント側で起こり得るエラー状態はほとんど無限でありアプリケーションに依存します。そのなかのいくつかはサーバーが起動された方法と直接関係するかもしれません。以下で説明する以外の状態については各々のクライアントアプリケーションの資料を参照してください。
psql: could not connect to server: Connection refused
Is the server running on host server.joe.com and accepting
TCP/IP connections on port 5432?
これは一般的な"接続するサーバーが見つけられませんでした"という失敗です。TCP/IP通信を試みたときに上記のような表示が出ます。よくある間違いはpostmasterにTCP/IPを許可する-iオプションを付け忘れていることです。
代わりに、ローカルのpostmasterにUnixソケット通信を試みると下記のような表示が出ます。
psql: could not connect to server: Connection refused
Is the server running locally and accepting
connections on Unix domain socket "/tmp/.s.PGSQL.5432"?
最後の行は、クライアントが正しいところに接続しようとしていることを実証するのに役立ちます。もしそこに動いているpostmasterがない場合、典型的なカーネルエラーメッセージは、表示されているように Connection refusedもしくは No such file or directoryとなります。(特にこの場合のConnection refusedはpostmasterが接続要求を受け付け拒否したわけではないということを理解しておくことが大切です。もしそうだった場合は Section 4.3で示されるような別のメッセージが表示されます）。Connection timed outのような他のメッセージは、たとえばネットワーク接続の欠如のようなもっと根本的な問題を表しています。