I am trying to use the Database Migration Service to migrate an existing database into CloudSQL.
When I start the migration, I receive the following error:
finished setup replication with errors: [api_production]: error importing schema: failed to restore schema: stderr=pg_restore: while PROCESSING TOC: pg_restore: from TOC entry 3997; 0 0 DATABASE PROPERTIES api_production postgres pg_restore: error: could not execute query: ERROR: permission denied to set parameter "log_min_duration_statement" Command was: ALTER DATABASE api_production SET log_min_duration_statement TO '500ms'; pg_restore: warning: errors ignored on restore: 1 , stdout=
How can I continue the migration, ignoring the SET PARAMETER statement?
I have finally been able to start the migration by resetting the parameters on the source database (setting them to match was insufficient).
This can be done from a postgres console on the source database:
reset log_min_duration_statement;
ALTER DATABASE <database_name> RESET log_min_duration_statement;
ALTER DATABASE postgres RESET log_min_duration_statement;
The Database Migration Service is a managed Google Cloud service, it has restricted access to certain system procedures and tables that require advanced privileges.The 'postgres' user is the most privileged user available in Cloud SQL, but it is not a Postgres superadmin. See public docs for more information about PostgreSQL Users.
There are some other parameters that you could run the "ALTER Database" command to change; however, "log_statement" and "log_min_duration_statement" are unfortunately not examples of these parameters.
The PostgreSQL documentation also documents this in particular "Certain variables cannot be set this way, or can only be set by a superuser."
However, you can change the particular setting in Console via the Flags on the database edit screen and remove these statements from the Migration job,to avoid these failure errors.
Please refer to the documentation to know more about configuring database flags.
Related
I'm new to Postgres and Heroku. I've inherited a project with a Postgres DB hosted on Heroku and I'd like to export it from there for local use inside Docker. I've got as far as exporting and then restoring (via pg_restore) the DB inside my container, but when it builds my DB I get loads of warnings like:
pg_restore: from TOC entry 285; 1259 16897 TABLE foo u2ae1fgct609sl
pg_restore: error: could not execute query: ERROR: role "u2ae1fgct609sl" does not exist
Command was: ALTER TABLE public.foo OWNER TO u2ae1fgct609sl;
Presumablty this is because I've exported/restored the DB but not the corresponding users. Heroku doesn't seem to mention this part in its docs on exporting/restoring/importing Postgres DBs.
What can I do about this? Can I somehow tell it to set as the owner the DB user that Docker created when spinning up the container, or am I on the wrong lines?
When I try to take PostgresDump (AWS RDS) the following error I am getting:
ERROR: permission denied for relation dms_stats_detailed
pg_dump: error: query was: LOCK TABLE table_name IN ACCESS SHARE MODE
I am having admin permission though (with Master User).
You need to run pg_dump with a database user (the -U option) that has permission to read the tables you are dumping.
I was given a database file , i don't know the userid who dumped it or it's privileges .
I use postgresql 9.6.7-1 with pg_admin4(v3.0) , OS: windows 10
First, i created a database in pgadmin with same name as the given file.
I used the restore option to restore the file but after some seconds
i got type of messages like :
pg_restore: executing SEQUENCE SET xxxx
pg_restore: [archiver (db)] Error from TOC entry 4309; 0 0 SEQUENCE SET xxxx postgres
pg_restore: [archiver (db)] could not execute query: ERROR: relation "public.xxxx" does not exist
LINE 1: SELECT pg_catalog.setval('public.xxxx', 1, false);
^
Command was: SELECT pg_catalog.setval('public.xxxx', 1, false);
and below all, the warning :
"WARNING: errors ignored on restore: 62"
comparing with other's answers i dont even get a single bit of data restored.
I have tried also with
pg_restore
command but i get the same result .
It looks like the dump you were given is not a complete backup. It only has the data, not the object definitions. That is, it was created by pg_dump using -a, --data-only, or --section=data.
Unless you already know what the object definitions are from some other source (e.g., an existing database server with the same schema definitions, or a dump file generated with pg_dump -s), you will have a hard time loading this data.
{solved}
please check the version of the Postgresql pgAdmin4 and the version of ".Sql" file you want to import into your database ,and instead of restoring at public you should directly restore at the database itself.
2:- drop the database and again re-create the fresh database(name='xyz') & at the same database ('xyz'** ->RightClick->Restore->Filename->'select(formate ".sql")->Restore**) than->refresh the database.
and by doing that it'll create i new Schema just above public Schema..
I'm trying to move a database in Postgres 8.2 to a new tablespace, but when running ALTER DATABASE data_base_name SET TABLESPACE TO tbspc_name
the following error appears ERROR: unrecognized configuration parameter "tablespace".
It seems that in Postgres 8.2 you have two options:
move tables one by one, see ALTER TABLE ...;
backup the database, create a new one with a tablespace defined, and restore the backup in the new database, see CRETE DATABASE ....
I want to export the different privileges in a DB2 9.7 database as DDL.
I found the following in the documentation:
https://www.ibm.com/support/knowledgecenter/SSEPGG_9.8.0/com.ibm.db2.luw.admin.gui.doc/doc/t0021930.html
Authorization statements: Generates SQL authorization (GRANT) statements for the database objects.
When I try to issue the command
db2look -d DatabaseName -u user
I get the following error:
SQL0552N "USER1" does not have the privilege to perform operation
"BIND". SQLSTATE=42502
When I try to give DBADM to the user1, I get the following error:
db2 "GRANT DBADM ON DATABASE TO USER USER1"
DB21034E The command was processed as an SQL statement because it was not a valid Command Line Processor command.
During SQL processing it returned:
SQL4707N Workload "SYSDEFAULTUSERWORKLOAD" cannot service the request
because the workload is not allowed to access the database or is disabled.
Reason code: "" SQLSTATE=5U020
I face this problem after restoring the database from a backup.
It seems that https://www-01.ibm.com/support/docview.wss?uid=swg21568865
did the trick:
db2set DB2_RESTORE_GRANT_ADMIN_AUTHORITIES=ON
Allows the instance user to execute the command.