From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | ceccareb(at)talusmusic(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #15263: pg_dump / psql failure. When loading, psql does not see function-based constraints or indices |
Date: | 2018-07-07 14:48:06 |
Message-ID: | 70632.1530974886@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
> On 06.07.18 18:19, PG Bug reporting form wrote:
>> When I load the database from the dump I just created, loading (via psql)
>> logs error messages. Postgres cannot find functions inside the function the
>> constraint or index invokes.
> I think this and your subsequent report are all instances of the problem
> that pg_dump cannot see into the function body to check what database
> objects it depends on, so it cannot produce a working ordering of the
> objects.
That's one possible issue, but I think a more likely cause is the recent
security-driven changes in the search_path that the restore script runs
with. If the function is relying on unqualified references to functions
that aren't in pg_catalog, it'll fail. (This theory explains why things
were okay with old copies of pg_dump.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | ceccareb@talusmusic.com | 2018-07-07 14:50:46 | Re: BUG #15263: pg_dump / psql failure. When loading, psql does not see function-based constraints or indices |
Previous Message | Tom Lane | 2018-07-07 14:35:30 | Re: long analyze, libc bug and libicu |