From: | Rich Shepard <rshepard(at)appl-ecosys(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Restoring database from backup |
Date: | 2024-12-13 19:26:37 |
Message-ID: | c277f544-7982-8d2d-8242-c7b543ae2191@appl-ecosys.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Fri, 13 Dec 2024, Adrian Klaver wrote:
> Alright, from here:
>
> https://www.postgresql.org/docs/current/app-pgdump.html
>
> "-c
> --clean
>
> Output commands to DROP all the dumped database objects prior to
> outputting the commands for creating them. This option is useful when the
> restore is to overwrite an existing database. If any of the objects do not
> exist in the destination database, ignorable error messages will be reported
> during restore, unless --if-exists is also specified.
>
> This option is ignored when emitting an archive (non-text) output file.
> For the archive formats, you can specify the option when you call pg_restore.
> "
>
> This means when you run the script with:
>
> psql -d bustrac -f bustrac-2024-12-12.sql
>
> it will clean out the current corrupted objects and replace them with those
> in the backup file.
Adrian,
That's what I thought since I wrote the script based on reading pgdump a
long time ago.
Thanks for confirming! I'll fix my carelessness now.
Carpe weekend,
Rich
From | Date | Subject | |
---|---|---|---|
Next Message | Peter J. Holzer | 2024-12-13 20:23:48 | Re: Credcheck- credcheck.max_auth_failure |
Previous Message | Durgamahesh Manne | 2024-12-13 19:23:55 | Subscriptions limit for 32cpus and 128gb |