Re: [HACKERS] CLUSTER command progress monitor - Mailing list pgsql-hackers

From Tattsu Yama
Subject Re: [HACKERS] CLUSTER command progress monitor
Date
Msg-id CAOKkKFs9e0_dbH+pVFnQEZ6epvYQKdY0sakrYbwMHNMbB8i3Kw@mail.gmail.com
Whole thread Raw
In response to [HACKERS] CLUSTER command progress monitor  (Tatsuro Yamada <yamada.tatsuro@lab.ntt.co.jp>)
Responses Re: [HACKERS] CLUSTER command progress monitor
List pgsql-hackers
Hi Alvaro!

 
Hello Tatsuro,
On 2019-Aug-13, Tatsuro Yamada wrote:
> On 2019/08/02 3:43, Alvaro Herrera wrote:
> > Hmm, I'm trying this out now and I don't see the index_rebuild_count
> > ever go up.  I think it's because the indexes are built using parallel
> > index build ... or maybe it was the table AM changes that moved things
> > around, not sure.  There's a period at the end when the CLUSTER command
> > keeps working, but it's gone from pg_stat_progress_cluster.
>
> Thanks for your report.
> I'll investigate it. :)
 
I have fixed it.  Can you please verify?


Thanks! I can review your patch for fix it.
However, I was starting fixing the problem from the last day of PGConf.Asia (11 Sep).
Attached file is WIP patch.In my patch, I added "command id" to all APIs of progress reporting to isolate commands. Therefore, it doesn't allow to cascade updating system views. And my patch is on WIP so it needs clean-up and test.
I share it anyway. :)

Here is a test result of my patch.
The last column index_rebuild count is increased.
========================================
postgres=# select * from pg_stat_progress_cluster ; \watch 0.001;
11636|13591|postgres|16384|CLUSTER|initializing|0|0|0|0|0|0
11636|13591|postgres|16384|CLUSTER|index scanning heap|16389|251|251|0|0|0
...
11636|13591|postgres|16384|CLUSTER|index scanning heap|16389|10000|10000|0|0|0
11636|13591|postgres|16384|CLUSTER|rebuilding index|16389|10000|10000|0|0|0...
11636|13591|postgres|16384|CLUSTER|rebuilding index|16389|10000|10000|0|0|1
...
11636|13591|postgres|16384|CLUSTER|rebuilding index|16389|10000|10000|0|0|2
...
11636|13591|postgres|16384|CLUSTER|rebuilding index|16389|10000|10000|0|0|3
...
11636|13591|postgres|16384|CLUSTER|rebuilding index|16389|10000|10000|0|0|4
...
11636|13591|postgres|16384|CLUSTER|performing final cleanup|16389|10000|10000|0|0|5
========================================

Thanks,
Tatsuro Yamada

Attachment

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: [HACKERS] [PATCH] pageinspect function to decode infomasks
Next
From: Michael Paquier
Date:
Subject: Re: pg_rewind docs correction