From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew@dunslane.net>
cc: jian he <jian.universality@gmail.com>,
        Mahendra Singh Thalor <mahi6run@gmail.com>,
        tushar <tushar.ahuja@enterprisedb.com>,
        Vaibhav Dalvi <vaibhav.dalvi@enterprisedb.com>,
        pgsql-hackers@lists.postgresql.org
Subject: Re: Non-text mode for pg_dumpall
In-reply-to: <84764ef6-2bcb-43f7-9037-d7b589857da9@dunslane.net>
References: <3f22a8bb-29e8-40cc-97a1-309181da2c13@dunslane.net> <CAC6VRoZbP=-=a+a78RoWcs2L4=4VEDZqJMg+7SyUAcSHATyDAQ@mail.gmail.com> <CAC6VRoY-1WC_O5UDwKzNc18LXLwjuTFb+qMNY3gaF3cCov6M6g@mail.gmail.com> <CAKYtNArc3j8Akb+nB1QyJLKic7ej7vKZqKnv_mbB+iQAJRzLnA@mail.gmail.com> <CAC6VRoat6NPcS6vfGrPrwaQB3G1JHLSqDeAkf1AJ7npWrwhnUQ@mail.gmail.com> <CAKYtNAp=TFEZWQbTRZso3kNaD9BH=-JPNQ30mT60cJN_04hEog@mail.gmail.com> <4022765f-38ee-48a3-b246-615b3f8e1c23@dunslane.net> <CAKYtNAq73_UeL4-0wgu9rawctHdS2zhpzWtqVuOChCS3M+2Ymg@mail.gmail.com> <CACJufxFs9NXXTeb78i2MD+pnZootayAtiGcNHNeU35SmQgMjbA@mail.gmail.com> <59d3616f-6d6d-40d5-87e2-e019e350b52d@dunslane.net> <CACJufxEnmJ8otfmN7Kp110Wqi=M4YE0-zn-W6SK+eTpWuZw_fg@mail.gmail.com> <CAKYtNAqxjQMLVPfz6XESqszhxZKgigi7UEBzBhz_Wj_Bnasdag@mail.gmail.com> <7faf3a59-cfe1-45cb-a972-55e05560b414@dunslane.net> <CACJufxE-zJiBAaZABtJBJr8FZdj=xP5adf_excmu9S6Op=KpLA@mail.gmail.com> <2e7ada75-422c-4153-9437-ea0ce8d63521@dunslane.net> <84764ef6-2bcb-43f7-9037-d7!
 b589857da9@dunslane.net>
Comments: In-reply-to Andrew Dunstan <andrew@dunslane.net>
	message dated "Thu, 26 Feb 2026 09:02:48 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <740032.1772142754.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Thu, 26 Feb 2026 16:52:34 -0500
Message-ID: <740033.1772142754@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/740033.1772142754%40sss.pgh.pa.us>
Precedence: bulk

Andrew Dunstan <andrew@dunslane.net> 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 semg=
et(668039, 17, 03600).
2026-02-26 20:18:10.389 UTC [14469:3] HINT:  This error does *not* mean th=
at 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 max=
imum number of semaphores (SEMMNS), would be exceeded.  You need to raise =
the respective kernel parameter.  Alternatively, reduce PostgreSQL's consu=
mption 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