He descargado una copia de seguridad limpia, sin propietario para la base de datos de Postgres con el comando
pg_dump sample_database -O -c -U
Más tarde, cuando restaure la base de datos con
psql -d sample_database -U app_name
Sin embargo, encontré varios errores que me impiden restaurar los datos:
ERROR: must be owner of extension plpgsql
ERROR: must be owner of schema public
ERROR: schema "public" already exists
ERROR: must be owner of schema public
CREATE EXTENSION
ERROR: must be owner of extension plpgsql
Investigué en el texto sin formato que pg_dump
genera SQL y encontré que contiene SQL
CREATE SCHEMA public;
COMMENT ON SCHEMA public IS 'standard public schema';
CREATE EXTENSION IF NOT EXISTS plpgsql WITH SCHEMA pg_catalog;
COMMENT ON EXTENSION plpgsql IS 'PL/pgSQL procedural language';
Creo que las causas son que el usuario app_name
no tiene los privilegios para alterar el public
esquema y plpgsql
.
¿Cómo puedo solucionar este problema?
postgresql
database-backups
rails-postgresql
Steveyang
fuente
fuente
plpgsql
, entoncesDROP EXTENSION plpgsql
antes que ustedpg_dump
. Esto es más seguro que convertir tu aplicación en un superusuario, y es más conveniente que ignorar los errores (lo que bombardea si usas--single-transaction
o-v ON_ERROR_STOP=1
). Este es un problema conocido, [discutido en profundidad por los desarrolladores de Postgres | postgresql.org/message-id/… pero no corregido a partir de 9.3.Respuestas:
Para resolver el problema, debe asignar los permisos de propiedad adecuados. Pruebe lo siguiente, que debería resolver todos los problemas relacionados con los permisos para usuarios específicos, pero como se indica en los comentarios, esto no debería usarse en producción:
Así que conéctese a la base de datos con una cuenta de superusuario
sudo -u postgres psql
y ejecute unaALTER ROLE <user-name> Superuser;
declaración.Tenga en cuenta que esta no es la mejor solución en el servidor de alojamiento de múltiples sitios, así que eche un vistazo a la asignación de roles individuales en su lugar: https://www.postgresql.org/docs/current/static/sql-set-role.html y https : //www.postgresql.org/docs/current/static/sql-alterrole.html .
fuente
app_user
es un superusuario.superuser
Usuarios de AWS RDS, si obtiene esto, es porque no es un superusuario y, de acuerdo con la documentación de AWS, no puede serlo. He descubierto que tengo que ignorar estos errores.
fuente
COMMENT ON EXTENSION
no esCREATE EXTENSION
. Elimine los comentarios y debería estar bien.Para las personas que usan Google Cloud Platform, cualquier error detendrá el proceso de importación. Personalmente, encontré dos errores diferentes según el comando pg_dump que emití:
1-
The input is a PostgreSQL custom-format dump. Use the pg_restore command-line client to restore this dump to a database.
Ocurre cuando ha intentado volcar su base de datos en un formato que no es de texto plano. Es decir, cuando el comando carece del parámetro -Fp o --format = plain. Sin embargo, si lo agrega a su comando, puede encontrar el siguiente error:
2-
SET SET SET SET SET SET CREATE EXTENSION ERROR: must be owner of extension plpgsql
Este es un problema de permisos que no he podido solucionar utilizando el comando proporcionado en los documentos de GCP , los consejos de este hilo actual o siguiendo los consejos del equipo de Google Postgres aquí . Lo que recomendó emitir el siguiente comando:
pg_dump -Fp --no-acl --no-owner -U myusername myDBName > mydump.sql
Lo único que funcionó en mi caso fue editar manualmente el archivo de volcado y comentar todos los comandos relacionados con plpgsql.
Espero que esto ayude a las almas que dependen de GCP.
Actualización:
Es más fácil volcar el archivo comentando las extensiones, especialmente porque algunos volcados pueden ser enormes:
pg_dump ... | grep -v -E '(CREATE\ EXTENSION|COMMENT\ ON)' > mydump.sql
Que se puede reducir a plpgsql:
pg_dump ... | grep -v -E '(CREATE\ EXTENSION\ IF\ NOT\ EXISTS\ plpgsql|COMMENT\ ON\ EXTENSION\ plpgsql)' > mydump.sql
fuente
pg_dump
comando exacto para usar en sus documentos :pg_dump -U [USERNAME] --format=plain --no-owner --no-acl [DATABASE_NAME] \ | sed -E 's/(DROP|CREATE|COMMENT ON) EXTENSION/-- \1 EXTENSION/g' > [SQL_FILE].sql
Probablemente pueda ignorar con seguridad los mensajes de error en este caso. No agregar un comentario al esquema público e instalar plpgsql (que ya debería estar instalado) no causará ningún problema real.
Sin embargo, si desea realizar una reinstalación completa, necesitará un usuario con los permisos adecuados. Por supuesto, ese no debería ser el usuario que su aplicación ejecuta habitualmente.
fuente
Respuesta más corta: ignóralo.
Este módulo es la parte de Postgres que procesa el lenguaje SQL. El error a menudo aparecerá como parte de la copia de una base de datos remota, como con un 'heroku pg: pull'. No sobrescribe su procesador SQL y le advierte sobre eso.
fuente
Intente usar la
-L
bandera con pg_restore especificando el archivo tomado depg_dump -Fc
https://www.postgresql.org/docs/9.5/app-pgrestore.html
Aquí puede ver que la inversa es verdadera al generar solo el comentario:
fuente
Para las personas que usan AWS ,
COMMENT ON EXTENSION
solo es posible como superusuario y, como sabemos por los documentos, las instancias de RDS son administradas por Amazon. Como tal, para evitar que rompa cosas como la replicación, sus usuarios, incluso el usuario raíz que configuró cuando creó la instancia, no tendrán privilegios de superusuario completos:http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.html
Para corregir este error, solo use
--
para comentar las líneas de SQL que contieneCOMMENT ON EXTENSION
fuente
pg_dump --no-comments
.Utilice el usuario de postgres (administrador) para volcar el esquema, recrearlo y otorgar privilegios para su uso antes de realizar la restauración. En un comando:
fuente
Para mí, estaba configurando una base de datos con pgAdmin y parece que establecer el propietario durante la creación de la base de datos no fue suficiente. Tuve que navegar hasta el esquema 'público' y establecer el propietario allí también (originalmente era 'postgres').
fuente
Para las personas que han reducido el problema a las
COMMENT ON
declaraciones (según varias respuestas a continuación) y que tienen acceso de superusuario a la base de datos de origen desde la que se crea el archivo de volcado, la solución más simple podría ser evitar que los comentarios se incluyan en el volcado. archivo en primer lugar, eliminándolos de la base de datos de origen que se está volcando ...Los volcados futuros no incluirán las
COMMENT ON
declaraciones.fuente
rails db:reset
en una instancia postgresql de AWS RDS sin tener que eliminar las líneas COMMENT ON del archivo de volcado cada vez que ejecuto un esquema migración.