> On Nov 11, 2025, at 06:33, Corey Huinker <corey.huinker@gmail.com> wrote:
>
>
> My attempts to test this all got stuck in wait_on_slots(). I haven't
> looked too closely, but I suspect the issue is that the socket never
> becomes readable because we don't send a query. If I set free_slot->inUse
> to false before printing the command, it no longer hangs. We probably want
> to create a function in parallel_slot.c to mark slots that we don't intend
> to give a query as idle.
>
> Would that be preferable to skipping the creation of extra connections for parallel workers? I can see it both ways.
Onthe one hand we want to give as true a reflection of "what would happen with these options", and on the other hand
onecould view the creation of extra workers as "real" vs a dry run.
>
>
I test the patch, but my first run was with no luck:
```
% vacuumdb --dry-run --echo -d evantest
SELECT pg_catalog.set_config('search_path', '', false);
vacuumdb: vacuuming database "evantest"
RESET search_path;
SELECT c.relname, ns.nspname FROM pg_catalog.pg_class c
JOIN pg_catalog.pg_namespace ns ON c.relnamespace OPERATOR(pg_catalog.=) ns.oid
CROSS JOIN LATERAL (SELECT c.relkind IN ('p', 'I')) as p (inherited)
LEFT JOIN pg_catalog.pg_class t ON c.reltoastrelid OPERATOR(pg_catalog.=) t.oid
WHERE c.relpersistence OPERATOR(pg_catalog.!=) 't'
AND c.relkind OPERATOR(pg_catalog.=) ANY (array['r', 'm'])
ORDER BY c.relpages DESC;
SELECT pg_catalog.set_config('search_path', '', false);
VACUUM (SKIP_DATABASE_STATS) pg_catalog.pg_proc; (not executed)
^CCancel request sent
^CCancel request sent
^CCancel request sent
^CCancel request sent
```
After skip the first vacuum command, the process got stuck, and ctrl-c couldn’t break it.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
