<P>PostgreSQL の開発は、PostgreSQL 開発メーリングリストに参加しているインターネット上の開発者チームですべて行なわれています。現在の座長は Marc G. Fournier ( <AHREF="mailto:scrappy@PostgreSQL.org">scrappy@PostgreSQL.org</A> )です。(以下に参加の仕方があります。)現在、このチームが PostgreSQL 開発のすべての面倒をみています。
<P>PostgreSQL の開発は、PostgreSQL 開発メーリングリストに参加している開発者達のチームですべて行なわれています。現在の座長は Marc G. Fournier (<AHREF="mailto:scrappy@PostgreSQL.org">scrappy@PostgreSQL.org</A> )です。(下記の<ahref="#1.6">1.6節</a>に参加の仕方があります。)現在、このチームが PostgreSQL 開発のすべての面倒をみています。
<P>Postgres95-1.01 の中心的な開発者は Andrew Yu と Jolly Chen でしたが、その他大勢の人々がこのコードの移植、テスト、デバグ、および、改良に参加しました。PostgreSQL の派生元コードである POSTGRES はカリフォルニア大学バークレイ校において、 Michael Stonebraker 教授の指揮のもと、多くの学生、卒業生、本職のプログラマたちの努力により作られました。
<P> MS Windows プラットホーム上で、<I>libpq</I> C ライブラリ、psql、それとその他のインターフェースは コンパイル可能で、バイナリーが走ります。この場合、クライアントを MS Windows 上で走らせて、TCP/IP 経由でサポートされている Unix プラットホーム上で走るサーバと通信します。
<P> MS Windows プラットホーム上で走せるために、<I>libpq</I> C ライブラリ、psql、その他のインターフェース、および、クライアントアプリケーションをコンパイルすることは可能です。この場合、クライアントを MS Windows 上で走らせて、TCP/IP 経由でサポートされている Unix プラットホーム上で走るサーバと通信します。</P>
<P> 現在、Cygnus Unix/NT 移植ライブラリの Cygwin を使って、PostgreSQL データベースサーバは Windows NT と Win2k 上で稼働しています。配布に含まれる<I>pgsql/doc/FAQ_MSWIN</I>あるいはウェブサイトにある MS Windows FAQ をご覧下さい。Microsoft の素のプラットホームに移植する計画はありません。<P>
<P><STRONG>サーバ</STRONG></P>
<P> 現在、Cygnus Unix/NT 移植ライブラリの Cygwin を使って、PostgreSQL データベースサーバは Windows NT と Win2k 上で稼働しています。配布に含まれる<I>pgsql/doc/FAQ_MSWIN</I>、あるいは、<Ahref="http://www.PostgreSQL.org/docs/faq-mswin.html">http://www.PostgreSQL.org/docs/faq-mswin.html</A>にある MS Windows FAQ をご覧下さい。</P>
PostgreSQLは他の商用あるいはオープンソースのデータベースと互角の性能も持ちます。ある面ではより早かったり、ほかの面ではより遅かったりします。MySQLなどの特化型データベース・システムにくらべて、PostgreSQLの挿入/更新が遅いのは、トランザクションによるオーバーヘッドがあるからです。もちろん、MySQLには上記の<I>Features</I>の節に示すような機能はまったくありません。我々は、PostgreSQLに柔軟性と機能性を組み込みながらも、絶えず、プロファイラーに掛けたりソースコードを解析したりして、性能の改善を続けています。PostgreSQL と MySQL とを比較している面白い Web ページが<Ahref="http://openacs.org/why-not-mysql.html">http://openacs.org/why-not-mysql.html</A>にあります。
<P>もしエラーメッセージが<I>IpcSemaphoreCreate: semget failed (No space left on device)</I>であれば、カーネルが十分なセマフォを使えるように構成されていません。Postgresは潜在的なバックエンドプロセス毎に一つのセマフォを必要とします。とりあえずの解決策は<I>postmaster</I>を起動するときに、バックエンドプロセスの数をより少なく制限をすることです。既定値の32より小さな数のパラメータを<I>-N</I>で使います。より恒久的な解決策は、カーネルの<small>SEMMNS</small> と <small>SEMMNI</small> パラメータを増やすことです。
<P>もしエラーメッセージが<I>IpcSemaphoreCreate: semget failed (No space left on device)</I>であれば、カーネルが十分なセマフォを使えるように構成されていません。Postgresは潜在的なバックエンドプロセス毎に一つのセマフォを必要とします。とりあえずの解決策は<I>postmaster</I>を起動するときに、バックエンドプロセスの数をより少なく制限をすることです。既定値の32より小さな数のパラメータを<I>-N</I>で使います。より恒久的な解決策は、カーネルの<SMALL>SEMMNS</SMALL> と <SMALL>SEMMNI</SMALL> パラメータを増やすことです。
<P>現在は、PostgreSQLのトランザクションのコミット時にラージ・オブジェクト・ハンドルを閉じることにより、<I>lo_open</I>コマンドが完了した直後に強制的にルールを実行します。このため、最初にハンドルに対して何かをしようとすると、<I>invalid large obj descriptor(ラージ・オブジェクトの記述子が不正)</I>となります。それで、もし、トランザクションを使うのを忘れると、(少なくともほとんどの時間)働いていたコードがエラーメッセージを出すのです。