| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Locking considerations of REINDEX |
| Date: | 2018-07-04 15:01:08 |
| Message-ID: | CAH2-Wzk8AY82wuV1Rkcj29AU11=JHeBV1Yd4foxH=hWizChbFw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Jul 4, 2018 at 5:08 AM, Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2018-07-04 15:22:10 | Re: Legacy GiST invalid tuples |
| Previous Message | Masahiko Sawada | 2018-07-04 14:24:32 | Failure assertion in GROUPS mode of window function in current HEAD |