Re: Locking considerations of REINDEX
От | Peter Geoghegan |
---|---|
Тема | Re: Locking considerations of REINDEX |
Дата | |
Msg-id | CAH2-Wzk8AY82wuV1Rkcj29AU11=JHeBV1Yd4foxH=hWizChbFw@mail.gmail.com обсуждение исходный текст |
Ответ на | Locking considerations of REINDEX (Pavan Deolasee <pavan.deolasee@gmail.com>) |
Список | pgsql-hackers |
On Wed, Jul 4, 2018 at 5:08 AM, Pavan Deolasee <pavan.deolasee@gmail.com> wrote: > But AFAICS get_relation_info() tries to lock every index and since REINDEX > will be holding a AEL on the index being reindexed, get_relation_info() > blocks. Since get_relation_info() gets into every read path, wouldn't a > concurrent REINDEX pretty much block every read access to the table, even if > REINDEX not holding AEL on the table itself? Not necessarily -- prepared statements may not block. > I wonder if we just need fix the docs to or if we actually regressed at some > point in the history or if we have a bug in the implementation? It mostly > seems like a case of wrongly written docs even though in theory it might be > possible to skip an index being rebuilt. I still agree with this, though. The practical distinction between getting an AEL on the table and what REINDEX does is pretty much indistinguishable from zero. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: