On 2026-02-26 Th 4:52 PM, Tom Lane wrote:
https://www.postgresql.org/message-id/2fb787be-79f2-4161-8ba4-24e8cab019ac%40dunslane.netAndrew
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?
No, I think it's just an oversight. I'll add this at the bottom of the loop:
+ $target_node->stop;
+ $target_node->clean_node;
More generally, perhaps we should have a DESTROY method in Cluster.pm
that would call the stop method when an object goes out of scope.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
