On 12/9/24 20:54, Ron Johnson wrote:
> On Mon, Dec 9, 2024 at 11:24 PM David G. Johnston
> <david.g.johnston@gmail.com <mailto:david.g.johnston@gmail.com>> wrote:
>
> On Monday, December 9, 2024, Ron Johnson <ronljohnsonjr@gmail.com
> <mailto:ronljohnsonjr@gmail.com>> wrote:
>
> On Sat, Nov 30, 2024 at 10:36 PM Adrian Klaver
> <adrian.klaver@aklaver.com <mailto:adrian.klaver@aklaver.com>>
> wrote:
> [snip]
>
> In future schema qualify all references.
>
> For now in the dump file you could search for
>
> SELECT pg_catalog.set_config('search_path', '', false);
>
> and set to
>
> SELECT pg_catalog.set_config('search_path', 'public', false);
>
>
> What if this had been a pg_dump --format={custom,directory} backup?
>
>
> pg_restore has a mode where it can dump out SQL to a script instead
> of directly restoring to the database.
>
>
> That Would Be Very, Very Bad if this were a database big enough to have
> required a multi-threaded dump.
From the original post:
https://www.postgresql.org/message-id/6a6439f1-8039-44e2-8fb9-59028f7f2014%40mailbox.org
"My HDD recently failed so I'm trying to restore my backup, but I'm
running into some errors."
There really was no choice.
Not tested but in the pg_restore case I could see at least trying:
1) pg_restore -s -f schema_definitions.sql custom_format_file
2) Then making the change in the search_path in schema_definitions.sql
and then load the schema in the database using psql
3) Then pg_restore -a -j <number_of_jobs> custom_format_file.
>
> --
> Death to <Redacted>, and butter sauce.
> Don't boil me, I'm still alive.
> <Redacted> lobster!
--
Adrian Klaver
adrian.klaver@aklaver.com
