[pgsql-jp: 40185] Re: REINDEX中のロックについて

[Takahito Yagami]

板垣さま

早速のご返答ありがとうございました。

> ただ、Prepared Statement を使わない場合や、REINDEX 中に PREPARE してしまうと、
> プランニングの最中にインデックスが使えるかどうか調べるために
> すべてのインデックスを共有ロックしてしまうため、そこで待たされます。
> 最終的にはそのインデックスを使わない実行計画になる場合であってもダメです。

まさに聞きたかった部分はここでした。
全ての処理を REINDEX 前に Prepared Statement するというのは
仕組み上難しそうなので、回避不可能ですね。

> この文自体には嘘は無いのですが、上記のような動作のため、実質的には
> 「REINDEX 中は、そのインデックスが張られたテーブルの読み書きはできない」
> として扱うしかないと思われます。

もともとREINDEX＝排他ロックというイメージはあったのですが、
サービス停止無しでREINDEXする方法がないかと思案しておりました。

例で書きました fulltextb の全文検索用INDEXは vacuum では
正規化されず、REINDEXせずにしばらくおくと検索結果にズレが
生じました。ですので、定期的な REINDEX が必要になってくると
思うのですが、みなさんこのような場合はどのようにメンテナンス
しているのでしょうか？



2010年2月17日16:03 Takahiro Itagaki <itagaki.takahiro ＠ oss.ntt.co.jp>:
>
> Takahito Yagami <yagami ＠ news2u.co.jp> wrote:
>
>> AccessExclusiveLock がSELECT文をブロックしていそうなのはわかるのですが、
>> 実行計画上で ロック中のインデックスを参照しなければ SELECTは
>> できると思っていましたが、上記が正常動作でしょうか？
>
> Prepared Statement を使い、REINDEX 前に実行計画がそのインデックスを
> 使わないよう固定されている場合に限り、REINDEX 中であっても
> その準備済み文を実行できます。
>
>   端末1  |  端末2
> ----------+-----------
>  PREPARE  |
>    ↓    | REINDEX
>  EXECUTE  |
>
> の順ならば、EXECUTE でブロックされないパターンを確認できるかと思います。
>
> ただ、Prepared Statement を使わない場合や、REINDEX 中に PREPARE してしまうと、
> プランニングの最中にインデックスが使えるかどうか調べるために
> すべてのインデックスを共有ロックしてしまうため、そこで待たされます。
> 最終的にはそのインデックスを使わない実行計画になる場合であってもダメです。
>
>> また、その場合マニュアルの「REINDEXはインデックスの元となるテーブルの
>> 書き込みをロックしますが、読み込みはロックしません。」という表現の
>> 意味するところはどうなるでしょうか？
>
> この文自体には嘘は無いのですが、上記のような動作のため、実質的には
> 「REINDEX 中は、そのインデックスが張られたテーブルの読み書きはできない」
> として扱うしかないと思われます。
>
> ------------------------------------------------------------
> NTT オープンソース ソフトウェア センタ
> 板垣貴裕 <itagaki.takahiro ＠ oss.ntt.co.jp>
>
>
>



-- 
============================================================
株式会社ニューズ・ツー・ユー
サービス部
矢上貴人（ヤガミタカヒト） <yagami ＠ news2u.co.jp>

〒102-0082
東京都千代田区一番町8　一番町ＦＳビル 5階
TEL：03-3512-0330　FAX：03-3512-0331
============================================================