| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
| Cc: | vaibhave postgres <postgresvaibhave(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: docs: warn about post-data-only schema dumps with parallel restore. |
| Date: | 2026-03-31 18:31:20 |
| Message-ID: | 2739511.1774981880@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)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 to
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="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>
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomas Vondra | 2026-03-31 18:33:15 | Re: EXPLAIN: showing ReadStream / prefetch stats |
| Previous Message | Tomas Vondra | 2026-03-31 18:27:21 | Re: Add pg_stat_vfdcache view for VFD cache statistics |