| From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
|---|---|
| To: | dominik(dot)hirt(at)hub28(dot)de, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #19407: pg_dump : DROP RULE creates forward references |
| Date: | 2026-02-13 22:16:59 |
| Message-ID: | aY-i27nIktxwhAww@nathan |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Fri, Feb 13, 2026 at 03:00:18PM -0600, Nathan Bossart wrote:
> On Fri, Feb 13, 2026 at 09:02:37AM +0000, PG Bug reporting form wrote:
>> During dump / restore with pg_dump / psql, I encounter a dependency ordering
>> issue that breaks the import when using ON_ERROR_STOP=on.
>>
>> Problem: pg_dump executes DROP RULE for specific views, forcing them to be
>> recreated before their dependencies (custom types, collations) exist in the
>> dump file, causing import failures.
>
> I think this is an even simpler reproducer:
>
> create type t as enum ('a', 'b');
> create table tt (a t primary key, b text);
> create view v as select * from tt group by a;
>
> Commit d8c05aff56 [0] did some work in this area, but this issue may even
> predate that. In any case, it seems like pg_dump needs to create the type
> before it creates the dummy view to deal with circular dependencies.
After some further investigation, I found this discussion from 2022 that
mentions the same problem:
https://postgr.es/m/flat/b43e03eb-3997-700e-c2d4-92c31e4e31ee%40dalibo.com
This led to commit 75af0f401f, which added some clarity to the
documentation for pg_dump's --clean and --if-exists options, but AFAICT we
don't actually say that using --if-exists with --clean is _not_ guaranteed
to prevent all errors due to nonexistent objects. Perhaps we should add
that information. I haven't looked into what it would take to actually fix
this issue, but from reading around I get the idea that it might not be
straightforward.
--
nathan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Noah Misch | 2026-02-13 22:48:04 | Re: BUG #19406: substring(text) fails on valid UTF-8 toasted value in PostgreSQL 15.16 |
| Previous Message | Thomas Munro | 2026-02-13 21:58:50 | Re: BUG #19406: substring(text) fails on valid UTF-8 toasted value in PostgreSQL 15.16 |