MIME-Version: 1.0
In-Reply-To: <2739511.1774981880@sss.pgh.pa.us>
References: 
 <CAM_eQjzTLtt1X9WKvMV6Rew0UvxT3mmhimZa9WT-vqaPjmXk-g@mail.gmail.com>
 <CAKFQuwbHpDVQt0=nfC7To=AxAkDs6fmvv-40Qcw6z=VtW23GEQ@mail.gmail.com>
 <1849705.1774809224@sss.pgh.pa.us>
 <CAKFQuwYtdN4chM2HzcNsOJMvsVqE2LnKGTvndNeGW8s66g0Acg@mail.gmail.com>
 <2739511.1774981880@sss.pgh.pa.us>
From: "David G. Johnston" <david.g.johnston@gmail.com>
Date: Tue, 31 Mar 2026 12:48:31 -0700
Message-ID: 
 <CAKFQuwaL5_7wmJ5nwXDn-Vc=vivOP6AB9U2Qyg5TgnzJ1pKNFw@mail.gmail.com>
Subject: Re: docs: warn about post-data-only schema dumps with parallel
 restore.
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: vaibhave postgres <postgresvaibhave@gmail.com>,
	"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Content-Type: multipart/alternative; boundary="00000000000089843d064e574084"
Archived-At: 
 <https://www.postgresql.org/message-id/CAKFQuwaL5_7wmJ5nwXDn-Vc%3DvivOP6AB9U2Qyg5TgnzJ1pKNFw%40mail.gmail.com>
Precedence: bulk

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

On Tuesday, March 31, 2026, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> "David G. Johnston" <david.g.johnston@gmail.com> writes:
> > But how about adding something like the following to the pg_dump notes?
> We
> > already have the corresponding link going to pg_dump in the pg_restore
> > notes.
>
> > "If producing a non-plaint-text format output see also the pg_restore
> > documentation for details on how the restore process uses the different
> > sections."
>
> Hmm, I think we could be a bit more definite than that.  What do you
> think of this advice:
>
>   <para>
>    When creating an archive (non-text) output file, it is advisable not t=
o
>    restrict the set of database objects dumped, but instead plan to apply
>    any desired object filtering when reading the archive
>    with <application>pg_restore</application>.  This will preserve
>    flexibility and possibly avoid problems at restore time; for details
>    see the <xref linkend=3D"app-pgrestore"/> documentation.  However,
>    omitting table data (<option>--no-data</option>) or large objects
>    (<option>--no-large-objects</option>) does not have any surprising
>    consequences.
>   </para>
>
>
I=E2=80=99m against including that final sentence.  The rest seems ok but I=
=E2=80=99
suggest going with an explicit mention that =E2=80=9C=E2=80=94no-schema is =
risky=E2=80=9D (or
otherwise omitting the entire section)

I have a nagging suspicion we could be a bit more precise; e.g., it=E2=80=
=99s
advisable to include the schema objects for the data that is being exported
only, not the entire schema always.  But we already mention that dealing in
subsets can introduce dependency issues so people have already been given
the alert there.  But data/no-schema seems like it should just work and
this just needs to warn them that it may not.

David J.

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

On Tuesday, March 31, 2026, Tom Lane &lt;<a href=3D"mailto:tgl@sss.pgh.pa.u=
s">tgl@sss.pgh.pa.us</a>&gt; wrote:<br><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">&quot=
;David G. Johnston&quot; &lt;<a href=3D"mailto:david.g.johnston@gmail.com">=
david.g.johnston@gmail.com</a>&gt; writes:<br>
&gt; But how about adding something like the following to the pg_dump notes=
?=C2=A0 We<br>
&gt; already have the corresponding link going to pg_dump in the pg_restore=
<br>
&gt; notes.<br>
<br>
&gt; &quot;If producing a non-plaint-text format output see also the pg_res=
tore<br>
&gt; documentation for details on how the restore process uses the differen=
t<br>
&gt; sections.&quot;<br>
<br>
Hmm, I think we could be a bit more definite than that.=C2=A0 What do you<b=
r>
think of this advice:<br>
<br>
=C2=A0 &lt;para&gt;<br>
=C2=A0 =C2=A0When creating an archive (non-text) output file, it is advisab=
le not to<br>
=C2=A0 =C2=A0restrict the set of database objects dumped, but instead plan =
to apply<br>
=C2=A0 =C2=A0any desired object filtering when reading the archive<br>
=C2=A0 =C2=A0with &lt;application&gt;pg_restore&lt;/<wbr>application&gt;.=
=C2=A0 This will preserve<br>
=C2=A0 =C2=A0flexibility and possibly avoid problems at restore time; for d=
etails<br>
=C2=A0 =C2=A0see the &lt;xref linkend=3D&quot;app-pgrestore&quot;/&gt; docu=
mentation.=C2=A0 However,<br>
=C2=A0 =C2=A0omitting table data (&lt;option&gt;--no-data&lt;/option&gt;) o=
r large objects<br>
=C2=A0 =C2=A0(&lt;option&gt;--no-large-objects&lt;/<wbr>option&gt;) does no=
t have any surprising<br>
=C2=A0 =C2=A0consequences.<br>
=C2=A0 &lt;/para&gt;<br><br>
</blockquote><div><br></div><div>I=E2=80=99m against including that final s=
entence.=C2=A0 The rest seems ok but I=E2=80=99 suggest going with an expli=
cit mention that =E2=80=9C=E2=80=94no-schema is risky=E2=80=9D (or otherwis=
e omitting the entire section)</div><div><br></div><div>I have a nagging su=
spicion we could be a bit more precise; e.g., it=E2=80=99s advisable to inc=
lude the schema objects for the data that is being exported only, not the e=
ntire schema always.=C2=A0 But we already mention that dealing in subsets c=
an introduce dependency issues so people have already been given the alert =
there.=C2=A0 But data/no-schema seems like it should just work and this jus=
t needs to warn them that it may not.</div><div><br></div><div>David J.</di=
v><div><br></div>

--00000000000089843d064e574084--