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

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

  1. Report progress of REINDEX operations

  2. Report progress of CREATE INDEX operations

  3. Fix error handling of readdir() port implementation on first file lookup