あと、日本語対応のODBCも入ってるみたい。

ChangeLog:
> 2001-03-16 08:03 inoue
>
> * src/interfaces/odbc/: multibyte.c, multibyte.h: Oops I forgot to
> add new files for multibyte support. Sorry Eiji.

だったらしい。

なお、ちゃんとした情報は、ChangeLogを参照してください。
ウソ書いてる可能性大。

この辺にプロトコル仕様出てるよ。
普通に psql の感覚でコマンド打ってもダメだよ。
http://www.postgresql.org/docs/programmer/protocol.htm

>>101
なかなか 7.1 Release 出ないね・・・。
石井さんは 2 月中って言っていたのに。結構難航しているのかな。

>>105
電動ナナシさんありがとうございました。
ちょっとむずかしくて解りませんでしたけど。
もしよかったらなんかサンプルコードありませんか？
例えばpg_userにアクセスするような。
HTTPがわかりやすすぎるのでしょうか？はぁ。

ど素人なんですけど
持続的接続はhttpdのpidごとに張るんですよね。
だからプロセスが変わるってのは変なのではないでしょうか？
ストアドだから張ったときのnow読んでいるって言う可能性は
ないのでしょうか？
この板にがんばって発言してみようと思ってるんですけど
ほんとど素人であーぱーナこといってすいません。

>>114
うーん、昨日から持続的接続のテストを始めて、
今日になって、'now'::timestampに昨日の日付のものが
登録されるようになったんです。

サーバは、昨日から立ち上げっぱなし、
クライントは、今日立ち上げたもの
です。

持続的接続は、クライアントがいなくなった場合、そのプロセス
は残っていて、接続要求があったときに、空いてるプロセス
があれば、そこにつなげる、というふうに思ってたんですが、
間違いでしょうか？

>>115
daemontoolsは、ちょっとスケジュールが厳しいので、
インストールして、調査、っていうのは厳しいなぁ。
来週火曜日までに、ひととおり作り上げ、来月稼動なので。

来週火曜日で承認されたら、また調査してみます。

持続的接続というのは、あくまで Apache/PHP <--> RDBMS 間の話というのは
いいよね。で、close() すると持続的接続でも接続解除されるというのも
いいよね。

で、持続的接続の場合には次のようになる。

例えば pgsql.max_persistent = 2 とするよ。
最初に pConnect() するよね。
・PHP の持続的接続数 = 1
次に pConnect() するよね。
・PHP の持続的接続数 = 2
次に pConnect() すると失敗
・持続的接続数 > max_persistent が成立

でも、次の場合はうまくいく。
最初に pConnect() する。
・PHP の持続的接続数 = 1
次に pConnect() する。
・PHP の持続的接続数 = 2
どれかがいったん close()
・PHP の持続的接続数 = 1
次に pConnect() する。
・PHP の持続的接続数 = 2

こんな感じになると思う。間違っていたらスマン。

あ、上のはあくまで別ホストに接続する場合だよ。

pConnect 関数は、過去の接続を覚えていて
・以前接続したのと同じコネクションがあれば、それを再利用
・そうでなければ接続
を行う。

で、「以前と同じ接続」かどうかは
"pgsql_HOSTNAME_PORT_OPTIONS_TTY_DBNAME"
という文字列で判断される。つまりホスト名、ポート番号、接続オプション、
端末名、データベース名の組み合わせがいっしょなら同じ接続、
そうでなければ別の接続になる。

pgsql.max_persistent は上記組み合わせの個数を制限するもの。
仮に Apache のプロセス数が 100 あっても、同じホストの同じ DB に接続
するなら、コネクションは一つしか張られないから max_persistent の
制限にはひっかからない。

あるコネクションへのアクセスが許可される Apache のプロセス数ではないよ。

ちなみに何でこのような持続的接続をするとかというと、
・セッション確立のコストが大きい（メモリと CPU に負荷を与える）
・WWW の場合、リクエスト単位で接続するとセッション確立・破棄が
　頻繁に行われることになり、さらに負荷がかかる
から。

で、複数リクエストを一つのデータベースセッションで処理することで
この問題を解決しようということで、持続的接続というアイデアが
生まれたんだよね。確かもともとはミドルウェア（トランザクション
モニタの Connection Pooling 機能）だと思った。

>>123
電動ナナシさん、いつもどうもです。
なんか、お手間を取らせてしまってすみません。

今、とんでもなくテンパッテるので、私の方の再試は水曜日以降に
なります。

>>128
それが私もどこで見かけたんだか忘れてしまいまして・・・

・まずブラウザでtest.phpを表示してみる。
　　→postgresのプロセスは残ったまま

・そのまま何回かリロードしてみる。
　　→postgresのプロセスは残ったまま。ただしプロセス数は増えない。

・時間を置いてリロードしてみる。
　　→規則性はわからないが、あるタイミングでプロセスは増えていく。

・どこまで増えるかはわかりません。

ps -ef | grep postgresの結果
postgres&nbsp;19528&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1&nbsp;&nbsp;0&nbsp;09:27&nbsp;?&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;00:00:00&nbsp;./postmaster&nbsp;-D&nbsp;/usr/local/pgsql
postgres&nbsp;23715&nbsp;19528&nbsp;&nbsp;0&nbsp;10:02&nbsp;?&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;00:00:00&nbsp;postgres:&nbsp;nobody&nbsp;test&nbsp;127.0.0.1
postgres&nbsp;23723&nbsp;19528&nbsp;&nbsp;0&nbsp;10:04&nbsp;?&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;00:00:00&nbsp;postgres:&nbsp;nobody&nbsp;test&nbsp;127.0.0.1
postgres&nbsp;23813&nbsp;19528&nbsp;&nbsp;0&nbsp;10:12&nbsp;?&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;00:00:00&nbsp;postgres:&nbsp;nobody&nbsp;test&nbsp;127.0.0.1
postgres&nbsp;24841&nbsp;19528&nbsp;&nbsp;0&nbsp;10:26&nbsp;?&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;00:00:00&nbsp;postgres:&nbsp;nobody&nbsp;test&nbsp;127.0.0.1

続く。

・lsofをインストールしてみましたが、使い方が良くわかりません(^^;

とりあえずオプション無しの結果。

postmaste&nbsp;24841&nbsp;postgres&nbsp;&nbsp;mem&nbsp;&nbsp;&nbsp;&nbsp;REG&nbsp;&nbsp;&nbsp;3,65&nbsp;&nbsp;1651925&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;817675&nbsp;/home2/local/pgsql7.1RC1/bin/postgres
postmaste&nbsp;24841&nbsp;postgres&nbsp;&nbsp;mem&nbsp;&nbsp;&nbsp;&nbsp;REG&nbsp;&nbsp;&nbsp;&nbsp;3,7&nbsp;&nbsp;&nbsp;492888&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;180226&nbsp;/lib/ld-2.1.3.so
postmaste&nbsp;24841&nbsp;postgres&nbsp;&nbsp;mem&nbsp;&nbsp;&nbsp;&nbsp;REG&nbsp;&nbsp;&nbsp;&nbsp;3,7&nbsp;&nbsp;&nbsp;&nbsp;79474&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;180244&nbsp;/lib/libcrypt-2.1.3.so
postmaste&nbsp;24841&nbsp;postgres&nbsp;&nbsp;mem&nbsp;&nbsp;&nbsp;&nbsp;REG&nbsp;&nbsp;&nbsp;&nbsp;3,7&nbsp;&nbsp;&nbsp;197984&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;180288&nbsp;/lib/libresolv-2.1.3.so
postmaste&nbsp;24841&nbsp;postgres&nbsp;&nbsp;mem&nbsp;&nbsp;&nbsp;&nbsp;REG&nbsp;&nbsp;&nbsp;&nbsp;3,7&nbsp;&nbsp;&nbsp;523855&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;180236&nbsp;/lib/libnsl-2.1.3.so
postmaste&nbsp;24841&nbsp;postgres&nbsp;&nbsp;mem&nbsp;&nbsp;&nbsp;&nbsp;REG&nbsp;&nbsp;&nbsp;&nbsp;3,7&nbsp;&nbsp;&nbsp;&nbsp;72276&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;180272&nbsp;/lib/libdl-2.1.3.so
postmaste&nbsp;24841&nbsp;postgres&nbsp;&nbsp;mem&nbsp;&nbsp;&nbsp;&nbsp;REG&nbsp;&nbsp;&nbsp;&nbsp;3,7&nbsp;&nbsp;&nbsp;545453&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;180228&nbsp;/lib/libm-2.1.3.so
postmaste&nbsp;24841&nbsp;postgres&nbsp;&nbsp;mem&nbsp;&nbsp;&nbsp;&nbsp;REG&nbsp;&nbsp;&nbsp;&nbsp;3,7&nbsp;&nbsp;&nbsp;174341&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;639164&nbsp;/usr/lib/libreadline.so.4.0
postmaste&nbsp;24841&nbsp;postgres&nbsp;&nbsp;mem&nbsp;&nbsp;&nbsp;&nbsp;REG&nbsp;&nbsp;&nbsp;&nbsp;3,7&nbsp;&nbsp;&nbsp;&nbsp;14837&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;180309&nbsp;/lib/libtermcap.so.2.0.8
postmaste&nbsp;24841&nbsp;postgres&nbsp;&nbsp;mem&nbsp;&nbsp;&nbsp;&nbsp;REG&nbsp;&nbsp;&nbsp;&nbsp;3,7&nbsp;&nbsp;5309068&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;180230&nbsp;/lib/libc-2.1.3.so

[考察]
うーん、全く進歩なし(^^;

えーと、ひょっとして気になさっている方がいるかもしれないので、
報告しておきます。

結局、現状理解の糸口さえ見つからない状態なので､
持続的接続を使うのは、とりあえず止めます。

PHP4.0.5 + PostgreSQL7.1がそろったあたりで、再チャレンジします。

持続的接続の謎解明？

仕事の合間に、いろいろとWebを検索してみたら、
「postgresプロセスが死ぬのは、対応するapacheプロセスが
死んだとき」
という情報にあたりました。
どっかの英語のBBSです。

今使っているサーバは、apacheを起動すると、apacheのプロセスが
10個立ち上がります。
で、これに空きがある場合は、HTTPリクエストをこれらのプロセスが
処理します。HTTPセッションが終了しても、これらのプロセスは
残ったままです。
持続的接続で立ち上がったpostgresプロセスは、これらのプロセス
との間に、DBセッションを確立します。
だから、close()しても、postgresプロセスは残ったままなんです。

・・・という線で自分を説得。多分正解。

ふうむ、そういうことなのかあ。
ソースちょっと追ったけど、connect() の場合と pconnect() の場合とで
ほとんど同じ処理をしているんだよね。単にリンク数のカウンタ処理部分が
違うくらいで。

connect() だと postgres は死んでくれるの？

謎だあ。もうちょっと追ってみよう。
# 暇ができたらだけど・・・。

>>136
>connect() だと postgres は死んでくれるの？

はい、死んでくれます。

>謎だあ。もうちょっと追ってみよう。

念の為書いときます。
configure optionの --enable-sigchildが、Oracleの持続的
接続を使う場合には必要という情報を見つけ、
リコンパイルしてみたんですが、これは関係ありませんでした。
オプション無しの場合と全く同じ挙動でした。

>>137
なんとなく原因がわかった雰囲気。

ひょっとして PostgreSQL だけでなく、あらゆる持続的接続の Close が
きちんとされてないという予測を立てたんだけど、追試できる人っている？

え、じゃああれでいいんだ。
馬鹿さらしてしまった。鬱だし脳。

149って気持ち悪いね
149って気持ち悪いね