Re: Adding REPACK [concurrently]
| От | Antonin Houska |
|---|---|
| Тема | Re: Adding REPACK [concurrently] |
| Дата | |
| Msg-id | 90700.1774627975@localhost обсуждение исходный текст |
| Ответ на | Re: Adding REPACK [concurrently] (Antonin Houska <ah@cybertec.at>) |
| Ответы |
Re: Adding REPACK [concurrently]
|
| Список | pgsql-hackers |
Antonin Houska <ah@cybertec.at> wrote: > Mihail Nikalayeu <mihailnikalayeu@gmail.com> wrote: > > src/backend/catalog/index.c:766,1464-1469 > > > > "bool progress = (flags & INDEX_CREATE_REPORT_PROGRESS) != 0;" > > > > AFAIU gin, hash and btree (at least) still just unconditionally write > > PROGRESS_CREATEIDX_* progress. > > I think you're right, I'll check it. I concluded this is a problem that exists for quite a while and should be fixed separately. Currently I don't see conflicts of parameter indexes between PROGRESS_COMMAND_REPACK and PROGRESS_COMMAND_CREATE_INDEX. There would be some if the index was built with the CONCURRENTLY option, but REPACK uses normal index build. I tried to write a patch that allows progress tracking of two commands at the same time (a "main command" and a "subcommand"), but regression tests revealed that contrib/file_fdw is broken in a way that I could not fix easily: during execution of a join, two COPY FROM commands are executed at the same time and they overwrite the status of each other. Unlike the concept of a sub-command, we cannot assume here that the command that started the reporting as the second will stop as the first. Thus in pgstat_progress_end_command() we cannot figure out which node is trying to stop the reporting. It needs more work, I can get back to it after PG 19 feature freeze. -- Antonin Houska Web: https://www.cybertec-postgresql.com
В списке pgsql-hackers по дате отправления: