| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Andreas Karlsson <andreas(at)proxel(dot)se> |
| Subject: | Re: v12.0: segfault in reindex CONCURRENTLY |
| Date: | 2019-10-17 08:33:22 |
| Message-ID: | 20191017083322.GA19372@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2019-Oct-17, Michael Paquier wrote:
> You may not have a backtrace, but I think that you are right:
> WaitForLockers() gets called in index_drop() with progress reporting
> enabled. index_drop() would also be taken by REINDEX CONCURRENTLY
> through performMultipleDeletions() but we cannot know if it gets used
> for REINDEX CONCURRENTLY or for DROP INDEX CONCURRENTLY as it goes
> through the central deletion machinery, so we have to mark progress
> reporting as true anyway. Maybe that's worth a comment in index_drop
> when calling WaitForLockers() because it is not actually that obvious,
> say like that:
Hmm, I wonder if it isn't the right solution to set 'progress' to false
in that spot, instead. index_drop says it must only be called by the
dependency machinery; are we depending on that to pass-through the need
to update progress status? I'm going over that code now.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | btendouan | 2019-10-17 08:35:10 | Re: pgbench - extend initialization phase control |
| Previous Message | Amit Kapila | 2019-10-17 08:30:21 | Re: [HACKERS] Block level parallel vacuum |