MIME-Version: 1.0
References: <3f22a8bb-29e8-40cc-97a1-309181da2c13@dunslane.net>
 <2bed001a-462c-42da-9a6b-3c7884502932@dunslane.net> <fd25e8b7-9538-4e44-90e5-8a357ac03eff@dunslane.net>
 <20250824010811.4d.nmisch@google.com> <82eb35b8-7f07-493b-b689-0934919e1dc3@dunslane.net>
 <CAKYtNAr+OMjcGKwd+AgWA+s=8EWGtg5PkVV3O7X6d3eCv=MUeQ@mail.gmail.com>
 <CAKYtNApzLLeCqt5fHDzZOTnzCdCnBt3Y_fytFmJ0LMNHDPY-yA@mail.gmail.com>
 <CAKYtNArSYJdjez541C0qPZ9R3_yzPDpScAd=-RU4kPRCJh4viQ@mail.gmail.com>
 <CAKYtNArGUTzrfTBxpftL_yAgkKE+hcDgXVfQvjB2HFO9rGhE5g@mail.gmail.com>
 <CA+vB=AEQc3Xqz+KMh35Zsa-SsRP-n=HXGT4RwwNou4-__Prx+A@mail.gmail.com>
 <CAKYtNAqJqDmKcqCzpHg2SO=2MTxvE7rOWCACsoWsO7520tUWKw@mail.gmail.com>
 <CA+vB=AE9ypeQV-hhXscJ6T75BrAFfZh56GX_eM=eVG2n1o_Beg@mail.gmail.com>
 <CA+vB=AGsn4eUxsbLk_oy=iKzd8D_1Ne375XH-2u6Zncu72Q01Q@mail.gmail.com>
 <CAKYtNAqQ5LHWNWyaeVOJaS=2xDJovfv9GShTBzf8_5s=jH7wsg@mail.gmail.com>
 <CAKYtNAoSTBqR24cn3XDOnwk2DCL+nAUkjpB5Xkz1H74rDqa-aQ@mail.gmail.com>
 <17555e46-4fb2-4265-90e0-95cb8ed584a6@dunslane.net> <CAKYtNAoz9JZC+-Uo4QsA1O0PkEehxhTFy1y3HJjqzv6jwrXvCQ@mail.gmail.com>
 <CA+vB=AETksQZpjyBosrZv6N5A6DjaCtMQop3+MB8GDj0XnYoxQ@mail.gmail.com>
 <CAKYtNAoEUvYEG207zaGY0pEh6TB2sk6hpuz9LdG-fYEC=e2CgQ@mail.gmail.com>
 <CAKYtNAppx6y7M+9Fb5+TtTNhRS6onZo9kHeQS6yQF7PiK6qnEA@mail.gmail.com>
 <CAC6VRoZie9-iC9gWcJs3QGx=2_tA34fMBmj7Ck0VAP2JpDJGug@mail.gmail.com>
 <CAC6VRoZHZWzHZ0Oh++WW=9Q83co4AyG6u4+7HVi1gJiuv1CZ2g@mail.gmail.com>
 <CAC6VRoYWPQZeLDuKVNeMz5z-iiVnv0zWyBwWhxdm4UQO17-AUQ@mail.gmail.com>
 <CAKYtNAoNi8O1wbSZx0a1oSi-YzQtprxqpfZqryRq39hXn_p-OA@mail.gmail.com>
 <CAC6VRoYCqJq=0q3GF+vfDVbY4JUehqsuxYhcmVi7A=1hfNzSJg@mail.gmail.com>
 <CAKYtNApm8nA6hVMNkSjeNPiwTZBWYkhJKU7haQghUZdw74tYxA@mail.gmail.com>
 <CACJufxHc5Rp2roGyJOVnCk=Mx8_42_9vCGJSCFpLB5=AFQqHTQ@mail.gmail.com> <CAKYtNAoz-Sz2X1ipkQ5x1Sh08AMyy1kDRGfeRW3P1W-QoN+WOg@mail.gmail.com>
In-Reply-To: <CAKYtNAoz-Sz2X1ipkQ5x1Sh08AMyy1kDRGfeRW3P1W-QoN+WOg@mail.gmail.com>
From: tushar <tushar.ahuja@enterprisedb.com>
Date: Wed, 7 Jan 2026 13:52:58 +0530
Message-ID: <CAC6VRoZU2L2GX7+bXpsZ6bo+NuxBOe1dTGDPzKobUL4KVdm46A@mail.gmail.com>
Subject: Re: Non-text mode for pg_dumpall
To: Mahendra Singh Thalor <mahi6run@gmail.com>
Cc: jian he <jian.universality@gmail.com>, 
	Vaibhav Dalvi <vaibhav.dalvi@enterprisedb.com>, pgsql-hackers@lists.postgresql.org
Content-Type: multipart/alternative; boundary="000000000000b336970647c8009b"
Archived-At: <https://www.postgresql.org/message-id/CAC6VRoZU2L2GX7%2BbXpsZ6bo%2BNuxBOe1dTGDPzKobUL4KVdm46A%40mail.gmail.com>
Precedence: bulk

--000000000000b336970647c8009b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jan 6, 2026 at 11:56=E2=80=AFAM Mahendra Singh Thalor <mahi6run@gma=
il.com>
wrote:

>
>
>
> We have another thread for this. We have patches also. Last year, we
> planned to block these databases at creation time.
>
> >
> > It's probably harmless, we connect to the databases further down to do
> actual work. But it's also not nice. The toc.glo seems to have a bunch of
> extraneous entries of type COMMENT and CONNECT. Why is that? As far as
> poible this should have output pretty much  identical to a plain pg_dumpa=
ll.
> >
> >
> > cheers
> >
> >
> > andrew
>
> If we don't dump those comments in non-text format, then the output of
> "pg_restore -f filename dump_non_text" will not be the same as the
> plain dump of pg_dumpall.
>
> Here, I am attaching an updated patch for the review and testing.
>
>
Hi Mahendra,

I found a scenario  in which the table is not
restored if --transaction-size switch is used  at the time of pg_restore
operation

Please refer this scenario:
Case A --pg_restore operation with "--transaction-size" against the  dump
(taken using pg_dump) -
create a table ( create table t(n int); )
perform pg_dump ( ./pg_dump -Ft postgres -f xyz.tar)
create a database (create database test;)
perform pg_restore using switch "--transaction-size" ( ./pg_restore
--transaction-size=3D1 -d test xyz.tar)
table is restored into test database

Case B --pg_restore operation with "--transaction-size" against the  dump
(taken using pg_dumpall) -
create a table ( create table t(n int); )
perform pg_dumpall ( ./pg_dumpall -Ft -f abc.tar)
create a new cluster, start the server against a different port
perform pg_restore using switch "--transaction-size" (./pg_restore -Ft
--transaction-size=3D10 -d postgres abc.tar -p 9000 -C)
table is not restored

if i remove --transaction-size switch then this works.

regards,

--000000000000b336970647c8009b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g=
mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Jan 6, =
2026 at 11:56=E2=80=AFAM Mahendra Singh Thalor &lt;<a href=3D"mailto:mahi6r=
un@gmail.com">mahi6run@gmail.com</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><br><br>
<br>
We have another thread for this. We have patches also. Last year, we<br>
planned to block these databases at creation time.<br>
<br>
&gt;<br>
&gt; It&#39;s probably harmless, we connect to the databases further down t=
o do actual work. But it&#39;s also not nice. The toc.glo seems to have a b=
unch of extraneous entries of type COMMENT and CONNECT. Why is that? As far=
 as poible this should have output pretty much=C2=A0 identical to a plain p=
g_dumpall.<br>
&gt;<br>
&gt;<br>
&gt; cheers<br>
&gt;<br>
&gt;<br>
&gt; andrew<br>
<br>
If we don&#39;t dump those comments in non-text format, then the output of<=
br>
&quot;pg_restore -f filename dump_non_text&quot; will not be the same as th=
e<br>
plain dump of pg_dumpall.<br>
<br>
Here, I am attaching an updated patch for the review and testing.<br><br></=
blockquote><div><br></div><div>Hi Mahendra,=C2=A0</div><div><br></div><div>=
I found a scenario=C2=A0 in which the table is not restored=C2=A0if=C2=A0--=
transaction-size switch is used=C2=A0 at the time of pg_restore operation=
=C2=A0</div><div><br></div><div>Please refer this scenario:</div><div>Case =
A --pg_restore operation with &quot;--transaction-size&quot; against the=C2=
=A0 dump (taken using pg_dump) -</div><div>create a table ( create table t(=
n int); )=C2=A0</div><div>perform pg_dump ( ./pg_dump -Ft postgres -f xyz.t=
ar)</div><div>create a database (create database test;)=C2=A0</div><div>per=
form pg_restore using switch &quot;--transaction-size&quot; ( ./pg_restore =
--transaction-size=3D1 -d test xyz.tar)=C2=A0</div><div>table is restored i=
nto test database=C2=A0</div><div><br></div><div>Case B --pg_restore operat=
ion with &quot;--transaction-size&quot; against the=C2=A0 dump (taken using=
 pg_dumpall) -</div><div><div>create a table ( create table t(n int); )=C2=
=A0</div><div>perform pg_dumpall ( ./pg_dumpall -Ft -f abc.tar)</div><div>c=
reate a new cluster, start the server against a different port=C2=A0</div><=
div>perform pg_restore using switch &quot;--transaction-size&quot; (./pg_re=
store -Ft --transaction-size=3D10 -d postgres abc.tar -p 9000 -C)</div><div=
>table is not restored=C2=A0</div><div><br></div><div>if i remove --transac=
tion-size switch then this works.=C2=A0</div><div><br></div><div>regards,</=
div><div>=C2=A0</div></div></div></div>

--000000000000b336970647c8009b--