Re: monitoring CREATE INDEX [CONCURRENTLY]
Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Rahila Syed <rahila.syed@2ndquadrant.com>,
Andres Freund <andres@anarazel.de>, Robert Haas <robertmhaas@gmail.com>,
Simon Riggs <simon@2ndquadrant.com>,
Pg Hackers <pgsql-hackers@lists.postgresql.org>,
David Fetter <david@fetter.org>, Pavan Deolasee <pavan.deolasee@gmail.com>,
Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
Date: 2019-04-05T20:46:28Z
Lists: pgsql-hackers
Attachments
- v2-0001-Report-progress-of-REINDEX-operations.patch (text/plain) patch v2-0001
On 2019-04-05 17:01, Alvaro Herrera wrote: > Users are going to wonder why the other phases don't appear to complete > for a long time :-) Keep in mind that the "waiting" phases are very > confusing to users. I suggest we just define additional phase numbers > for those phases, then switch the "false" argument to > WaitForLockersMultiple to "true", and it should work :-) Doc-wise, list > all the phases in the same docbook table, indicate that REINDEX is also > covered, and document in an easier-to-follow fashion which phases each > command goes through. Done in the attached patch. I've reworded the phases a bit. There was a bit of a mixup of waiting for snapshots and waiting for lockers. Perhaps not so important from a user's perspective, but at least now it's more consistent with the source code comments. > Yeah, I think that's simple enough -- the CLUSTER one already does that, > I think. Added that. > Another thing for REINDEX TABLE is that we should add a count > of indexes to process, and how many are done. Reasonable, but maybe a bit too much for the last moment. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Commits
-
Report progress of REINDEX operations
- 03f9e5cba0ee 12.0 landed
-
Report progress of CREATE INDEX operations
- ab0dfc961b6a 12.0 landed
-
Fix error handling of readdir() port implementation on first file lookup
- 754b90f657bd 12.0 cited