Re: [HACKERS] CLUSTER command progress monitor

Поиск
Список
Период
Сортировка
От Tattsu Yama
Тема Re: [HACKERS] CLUSTER command progress monitor
Дата
Msg-id CAOKkKFs9e0_dbH+pVFnQEZ6epvYQKdY0sakrYbwMHNMbB8i3Kw@mail.gmail.com
обсуждение исходный текст
Ответ на [HACKERS] CLUSTER command progress monitor  (Tatsuro Yamada <yamada.tatsuro@lab.ntt.co.jp>)
Ответы Re: [HACKERS] CLUSTER command progress monitor  (Michael Paquier <michael@paquier.xyz>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: [HACKERS] [PATCH] pageinspect function to decode infomasks
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: pg_rewind docs correction