Al fin luego de tanto batallar pudimos hallar el arreglo de este atasco que muchos lectores de este sitio web tienen. Si deseas compartir algún detalle no dudes en dejar tu conocimiento.
Solución:
El error es inofensivo, pero para deshacerse de él, creo que debe dividir esta restauración en dos comandos, como en:
dropdb -U postgres mydb &&
pg_restore --create --dbname=postgres --username=postgres pg_backup.dump
los --clean La opción en pg_restore no parece gran cosa, pero en realidad plantea problemas no triviales.
Para versiones hasta 9.1
La combinación de --create y --clean en las opciones de pg_restore solía ser un error en versiones anteriores de PG (hasta 9.1). De hecho, existe cierta contradicción entre (citando la página de manual de 9.1):
–clean Limpiar (soltar) objetos de la base de datos antes de volver a crearlos
y
–create Crea la base de datos antes de restaurarla.
Porque, ¿cuál es el punto de limpiar dentro de una base de datos nueva?
A partir de la versión 9.2
La combinación ahora se acepta y el documento dice esto (citando la página de manual 9.3):
–clean Limpie (elimine) los objetos de la base de datos antes de volver a crearlos. (Esto podría generar algunos mensajes de error inofensivos, si algún objeto no estuviera presente en la base de datos de destino).
–create Crea la base de datos antes de restaurarla. Si también se especifica –clean, suelte y vuelva a crear la base de datos de destino antes de conectarse a ella.
Ahora, tener ambos juntos conduce a este tipo de secuencia durante la restauración:
DROP DATABASE mydb;
...
CREATE DATABASE mydb WITH TEMPLATE = template0... [other options]
...
CREATE SCHEMA public;
...
CREATE TABLE...
No hay DROP para cada objeto individual, sólo un DROP DATABASE al principio. si no usa --create esto sería todo lo contrario.
De todos modos esta secuencia plantea el error de public esquema ya existente porque la creación mydb de template0 ya lo ha importado (lo cual es normal, es el punto de una base de datos de plantilla).
No estoy seguro de por qué este caso no es manejado automáticamente por pg_restore. Tal vez esto cause efectos secundarios no deseados cuando un administrador decida personalizar template0 y/o cambiar el propósito de publicincluso si se supone que no debemos hacer eso.
En mi caso, la razón fue que estaba usando pg_restore de postgresql-contrib versión 11.2 para restaurar un volcado realizado por pg_dump 9.6 a un clúster de PostgreSQL 9.6.
Después de que rebajé mi pg_restore de vuelta a 9.6, esto schema "public" already exists el error desapareció y el proceso de restauración funcionó como antes.
La restauración incluye el esquema público y también crea la base de datos. Por lo tanto, elimine el esquema después de crear la base de datos para que la restauración pueda crearla sin errores.
Nota: A continuación se supone que -h -U -p son valores predeterminados y se establece PGPASSWORD o .pgpass
psql << XENDX
drop database if exists DB_NAME;
create database DB_NAME;
/c DB_NAME;
drop schema if exists public;
create schema public;
XENDX
pg_restore -d DB_NAME FILE_CREATED_WITH_pg_dump