On Mon, Sep 21, 2026 at 6:34 AM Jingtang Zhang <[email protected]> wrote:
>
> Hi Andrey,
>
> Thanks for the review!
>
> > distinguish the leader from its workers. Perhaps a comment at the
> > macro definition noting that autovacuum's parallel workers return
> > false would help prevent similar mistakes.
>
> Attached is v2 with the comment you suggested for
> AmAutoVacuumWorkerProcess().
Thank you for the report and the patch! I think the following comment
should also be updated:
* When running in an autovacuum worker, we won't necessarily _fully_
* empty the pending list. This is still safe; concurrent inserters
* cannot insert new tuples whose TIDs VACUUM needs us to remove.
How about something like this:
* When called by autovacuum, we won't necessarily _fully_ empty the
* pending list. This is still safe; concurrent inserters cannot insert
* new tuples whose TIDs VACUUM needs us to remove.
The reset looks good to me.
>
> > Could we cover the parallel-worker path with a test? One possible
> > scenario is to pause cleanup while flushing the old tail into the main
> > index, append new pending pages, and verify that cleanup leaves those
> > new pages behind. The test would need to ensure that a parallel worker,
> > not the leader, handles the index; otherwise it could pass without
> > the fix. I have not tried this scenario yet.
>
> For the test, I haven't found a reliable way to control the timing
> without adding injection points. We need to ensure that a parallel
> worker handles the index, and append new pending pages while cleanup
> is flushing the old tail into the main index.
>
> Do you have any ideas for a simpler way to test this?
Having a reliable test at a convenient cost seems challenging to me,
and doesn't justify its benefit. I think we can push it without a
test.
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
