Andrew Dunstan <[email protected]> writes:
> pushed with a slight tweak.
BF member pollock isn't pleased with 007_pg_dumpall:
026-02-26 20:18:10.389 UTC [14469:1] FATAL: could not create semaphores: No
space left on device
2026-02-26 20:18:10.389 UTC [14469:2] DETAIL: Failed system call was
semget(668039, 17, 03600).
2026-02-26 20:18:10.389 UTC [14469:3] HINT: This error does *not* mean that
you have run out of disk space. It occurs when either the system limit for the
maximum number of semaphore sets (SEMMNI), or the system wide maximum number of
semaphores (SEMMNS), would be exceeded. You need to raise the respective
kernel parameter. Alternatively, reduce PostgreSQL's consumption of semaphores
by reducing its "max_connections" parameter.
It looks to me like this is happening because the script creates a
boatload of postmasters and doesn't bother to shut any of them down
(until that happens implicitly at script end). That seems rather
unfriendly to small BF machines in the first place, as well as for
installations that might try to run multiple TAP scripts in parallel.
It's probably eating an undue amount of disk space, as well.
Is there a reason why the "foreach my $run (sort keys %pgdumpall_runs)"
loop leaves the $target_nodes running, instead of cleaning each one
up at the bottom of the loop?
regards, tom lane
