Thanks for the feedback and I apologize for the delay in response.
> I think the problem here is that you're basically trying to work around the
> lack of an asynchronous state update mechanism between leader and workers. The
> workaround is to add a lot of different places that poll whether there has
> been any progress. And you're not doing that by integrating with the existing
> machinery for interrupt processing (i.e. CHECK_FOR_INTERRUPTS()), but by
> developing a new mechanism.
> I think your best bet would be to integrate with HandleParallelMessages().
You are correct. I have been trying to work around the async nature
of parallel workers performing the index vacuum. As you have pointed out,
integrating with HandleParallelMessages does appear to be the proper way.
Doing so will also avoid having to do any progress updates in the index AMs.
In the attached patch, the parallel workers send a new type of protocol message
type to the leader called 'P' which signals the leader that it should handle a
progress update. The leader then performs the progress update by
invoking a callback set in the ParallelContext. This is done inside HandleParallelMessages.
In the index vacuum case, the callback is parallel_vacuum_update_progress.
The new message does not contain a payload, and it's merely used to
signal the leader that it can invoke a progress update.
Also, If the leader performs the index vacuum, it can call parallel_vacuum_update_progress
directly inside vacuumparallel.c.
Regards,
Sami Imseih
Amazon Web Services (AWS)