[pgsql-jp: 31746] Re: デッドロックの解決になるかも

Wataru Oguro oguro @ zenrin-datacom.net
2003年 12月 10日 (水) 09:54:56 JST


oguroです。

三谷様、早速のご対応とお返事、深く感謝いたします。。。
お世話になりっぱなしで申し訳ありませんが、お体に気をつけてこれからも頑
張ってくださいませ。

引き続き検証しておりますので、また何か見つけましたらご報告したいと思います。

mitani wrote:

> 三谷@広島です.
> 
> 
>>そのとおりですが、PG_CLUSTERで実験すると分かると思いますが、2種類のデッ
>>ドロックのパターンがあります。
> 
> レプリケーションサーバとクラスタサーバ間の通信は,データ整合性を取るためと,パ
> フォーマンスを上げるためにコネクションプーリングを使っています.これが問題を引
> き起こしている可能性が考えられます.
> 次バージョンではこのキューの部分を,物理的に1本のプロセスやソケットでの実装をや
> め,複数プロセス・複数ソケットを使って仮想的にキューを実現する方式に変更しまし
> た.
> 
> 次バージョンは他にも以下の不具合を修正しました.
> 1.0.5からの機能追加はありませんが,かなり重要な修正を含んでいますので,バージョ
> ンアップされることをお薦めします.
> 
> <<1.0.6で修正した不具合>>
> ・セッション処理中のクラスタサーバに障害が発生した場合,フェールオーバ−が失敗
> する.
> ・リカバリー時にpg_controlが削除されるので,リカバリーに失敗すると起動できなく
> なる.
> ・rsyncに失敗すると(パスワードを聞いてくるような場合),レプリケーションサーバ
> がレプリケーション要求を受け付けなくなる.
> ・クライアントのエンコードとDBのエンコードが異なる場合,レプリケーションされた
> クラスタサーバで文字化けが発生する.
> ・pg_dumpでとったバックアップをロードバランサを経由してリストアする場合,
> バックアップファイルの中に1024Byteを超えるSQL文があるとセッションが切れる.
> ・複数のセッションから同時に大量のデータ更新を行うと,更新処理の順番はクラスタ
> サーバのカーネルスケジューリングに依存するため,データ追加・更新の順番が保証さ
> れない.
> 
> 次バージョンはHPの準備が出来次第(今週中が目標),リリースしたいと思っています.
> 
> 
> =============================
> 三谷 篤<mitani @ sraw.co.jp>
> =============================





pgsql-jp メーリングリストの案内