| From: | Yuhang Qiu <iamqyh(at)gmail(dot)com> |
|---|---|
| To: | Jingtang Zhang <mrdrivingduck(at)gmail(dot)com> |
| Cc: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, pgsql-hackers mailing list <pgsql-hackers(at)lists(dot)postgresql(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Peter Geoghegan <pg(at)bowt(dot)ie>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
| Subject: | Re: [PATCH] Use bounded GIN pending-list cleanup in parallel autovacuum |
| Date: | 2026-09-23 07:58:25 |
| Message-ID: | 86E8514B-35DD-42F3-9386-360595E94032@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Jingtang,
The fix in v2 LGTM. I used local injection points to test both
ginbulkdelete() and the ginvacuumcleanup() path where bulk deletion was
not performed.
The test ensures that a parallel worker handles the GIN index. It pauses
cleanup at the original tail page, after releasing the buffer content
lock, then appends new pending pages from another session. Without the
fix, both paths continue until the pending list is empty. With v2, both
leave new pending pages behind, matching serial autovacuum. Manual
parallel VACUUM still empties the pending list.
> Do you have any ideas for a simpler way to test this?
I haven't found a simpler, reliable way to test this without adding
injection points either. Given the extra machinery needed to test such
a small fix, I'd lean toward leaving it without a regression test.
Best regards,
Yuhang Qiu
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Zsolt Parragi | 2026-09-23 08:10:19 | Re: Serverside SNI support in libpq |
| Previous Message | Sagar Shedge | 2026-09-23 07:54:41 | Re: postgres_fdw: push down FETCH FIRST .. WITH TIES when server version allows |