Re: docs: warn about post-data-only schema dumps with parallel restore.

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-29 18:33:44
Message-ID: 1849705.1774809224@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:
> On Sun, Jan 25, 2026 at 10:23 PM vaibhave postgres <
> postgresvaibhave(at)gmail(dot)com> wrote:
>> Following up on the discussion in [1] about pg_restore failing to restore
>> post-data items due to circular foreign key deadlocks.
>> I’m attaching a doc patch that adds a warning about using post-data-only
>> schema dumps together with parallel restore.

> Not a fan of the patch overall though. I'd want to add something to
> pg_restore noting that use of --jobs for constraint restoration needs
> schema information to compute the restoration order.

Yeah, dropping this into the list of options is bad. We put caveats
like that into the Notes section usually.

I also tend to think that it'd be better to document this under
pg_restore: when people run into this type of failure, they are going
to go to the pg_restore docs not the pg_dump docs to understand it.
I guess there could be a case for repeating the info in both the
pg_dump and pg_restore pages, but that feels a bit verbose.

So maybe like the attached?

regards, tom lane

Attachment Content-Type Size
v2-0001-doc-warn-about-post-data-only-schema-dumps-with-para.patch text/x-diff 1.2 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2026-03-29 18:34:39 Re: [PATCH] pg_dump: Restore extension config table data before user objects during pg_upgrade
Previous Message SATYANARAYANA NARLAPURAM 2026-03-29 18:31:49 Re: Add max_wal_replay_size connection parameter to libpq