| From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
|---|---|
| To: | Dmitry Dolgov <9erthalion6(at)gmail(dot)com> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, James Coleman <jtc331(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: remove spurious CREATE INDEX CONCURRENTLY wait |
| Date: | 2020-11-27 16:53:07 |
| Message-ID: | 20201127165307.GA13721@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Actually, I noticed two things. The first of them, addressed in this
new version of the patch, is that REINDEX CONCURRENTLY is doing a lot of
repetitive work by reopening each index and table in the build/validate
loops, so that they can report progress. This is easy to remedy by
adding a couple more members to the new struct (which I also renamed to
ReindexIndexInfo), for tableId and amId. The code seems a bit simpler
this way.
The other thing is that ReindexRelationConcurrenty seems to always be
called with the relations already locked by RangeVarGetRelidExtended.
So claiming to acquire locks on the relations over and over is
pointless. (I only noticed this because there was an obvious deadlock
hazard in one of the loops, that locked index before table.) I think we
should reduce all those to NoLock. My patch does not do that.
| Attachment | Content-Type | Size |
|---|---|---|
| reindex-concurrently-2.patch | text/x-diff | 15.7 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephen Frost | 2020-11-27 16:56:31 | Re: proposal: possibility to read dumped table's name from file |
| Previous Message | Heikki Linnakangas | 2020-11-27 16:49:57 | Re: Removing unneeded self joins |