Re: pg_dump/restore failure (dependency?) on BF serinus - Mailing list pgsql-hackers

From Andres Freund
Subject Re: pg_dump/restore failure (dependency?) on BF serinus
Date
Msg-id pautddzupf55bvgjjqmoqm7bq4gl67lmnmkwxkhf42yr5likix@ujxwq6yqpsvb
Whole thread Raw
In response to Re: pg_dump/restore failure (dependency?) on BF serinus  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg_dump/restore failure (dependency?) on BF serinus
List pgsql-hackers
Hi,

On 2025-04-08 00:11:55 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> >> # Running: pg_restore --create -j2 -d postgres
/home/bf/bf-build/serinus/HEAD/pgsql.build/testrun/pg_upgrade/002_pg_upgrade/data/tmp_test_KTss/regression.dump
> >> pg_restore: error: could not execute query: ERROR:  there is no unique constraint matching given keys for
referencedtable "pk"
 
> >> Command was: ALTER TABLE fkpart5.fk
> >> ADD CONSTRAINT fk_a_fkey FOREIGN KEY (a) REFERENCES fkpart5.pk(a);
> 
> > It's hard to tell without more logging, but the most likely explanation for
> > this seems that somehow the primary key on fkpart5.pk hasn't yet been
> > restored. However, looking at the pg_restore -v -l of the regression test
> > database locally, the relevant dependencies look sane on a first glance.
> 
> This feels quite adjacent to my complaint here:
> 
> https://www.postgresql.org/message-id/2045026.1743801143%40sss.pgh.pa.us
> 
> though perhaps it's not exactly the same.

That does sound rather plausible. What an odd coincidence that it failed like
that so close to your email. While this specific failure probably couldn't
have happened much earlier, it seems that it could have as part of pg_upgrade
for longer.


> I plan to start looking into a fix for that tomorrow.

Cool.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_dump/restore failure (dependency?) on BF serinus
Next
From: Tom Lane
Date:
Subject: Re: [PoC] Reducing planning time when tables have many partitions