I have a postgres 9.6. I am using pg_dumpall with -c --if-exists options.
When I restore from this backup file as the superuser I am getting errors current user cannot be dropped when it tries to drop the role. And after that I am getting role "mysuperuser" already exists when it tries to create the superuser role.
These two errors does not effect the success of the restore. However, I do not want to get irrelevant errors like these.
What I can do is to remove the two lines which are dropping and creating the aforementioned superuser role.
Is there a better way to do this? Because in order to achieve that I need to open a huge file and edit it.
You might want to join one of the postgreql.org mailing list and see if this irritation has occurred for others. It's clearly not the ideal behaviour.
There is a simple work-around though. Create a new superuser (that doesn't exist in the backup) and use that user to do the restore.
Related
I want to get a full backup of postgres 9.6. Including the users and permissions. However I want to exclude some tables. In pg_dump there is an option for excluding some tables (-T). However in pg_dumpall there are no such options.
Is there a way for getting a backup like this in a single command? Or should I get pg_dumpall (without tables) and pg_dump with -T? However in the second scenario these two dumps are not completely synchronised.
You'll have to use pg_dumpall -g and pg_dump -T.
True, the dumps will not share a single snapshot, but unless you add, modify or delete users and tablespaces very frequently, that should not be a problem in practice.
Yesterday I created a user to make backups from PostgreSQL. I granted select to this user and then I noticed that the name was not well written. The problem is that I tried to erase the user using the command line and the response was, due to the grants that I made a few moments back:
ERROR: role "dump_user" cannot be dropped because some objects depend on it
Long story short, I erased this user using pgadmin and now I have problems because when I want to create a new table, it tells:
ERROR: role 313898229 was concurrently dropped
I cheked and 313898229 was the oid of this dump_user in the pg_authid table, I tried to create a new user and assign this oid, but postgres says that I can't modify system id "oid".
Is there a way that I can permanently erase this user?
If all you wanted was a different name:
ALTER ROLE dump_user RENAME TO better_name;
Too late for that now. Before deleting the role you should have run:
REASSIGN OWNED BY pg_dump TO postgres; -- postgres being default superuser role
Read details here:
Find objects linked to a PostgreSQL role
Your error message:
ERROR: role 313898229 was concurrently dropped
is defined in the source code here. Looks like a race condition between two transactions. But you omitted relevant details.
Using: Postgres 9, CentOS 7,
Postgres Data directory not in default location but used RSync to make sure permissions were correct. And yes appropriate .config files were changed.
When I try to query a view containing an encrypted item as a NON superuser (Testuser), I get this error:
ERROR: must be superuser to read files CONTEXT: PL/pgSQL function
decrypt_data(bytea) line 13 at assignment
If I run that same query using POSTGRES superuser, the query completes fine.
This seems to be a file system read permission error when trying to read the Key files. Everything I see using encryption seem to not mention how to run without being superuser.
I have already run the following grants for Testuser:
GRANT ALL PRIVILEGES ON DATABASE xxx_db to Testuser;
GRANT SELECT ON ALL TABLES IN SCHEMA xxxxx TO Testuser;
GRANT ALL ON ALL TABLES IN SCHEMA xxxxx TO Testuser;
The test user can create tables, views, basically anything within that db.. just not read encryption keys.
The permissions on the keys are 775 right now, I even tried 777 without luck.
Any Ideas?
pgcrypto is a PostgreSQL extension described here:
https://www.postgresql.org/docs/current/static/pgcrypto.html
but it doesn't provide a decrypt_data(bytea) function.
This function seems to be custom code that happens to open a server-side file, with pg_read_file() or a similar method.
These methods are restricted to superusers to avoid normal users to read on the server's filesystem, no matter what are the Unix rights of the particular file they want to read.
You can verify this in the source of decrypt_data(bytea), which can be obtained with:
select pg_get_functiondef('decrypt_data(bytea)'::regprocedure);
or \df+ decrypt_data(bytea) from within psql.
I found the issue. I need to grant the user with function permissions.
GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA xxxxx TO yyyyyyyyy;
I tried pg_dump and then on a separate machine I tried to import the sql and populate the database, I see
CREATE TABLE
ERROR: role "prod" does not exist
CREATE TABLE
ERROR: role "prod" does not exist
CREATE TABLE
ERROR: role "prod" does not exist
CREATE TABLE
ERROR: role "prod" does not exist
ALTER TABLE
ALTER TABLE
ALTER TABLE
ALTER TABLE
ALTER TABLE
ALTER TABLE
ALTER TABLE
WARNING: no privileges could be revoked for "public"
REVOKE
ERROR: role "postgres" does not exist
ERROR: role "postgres" does not exist
WARNING: no privileges were granted for "public"
GRANT
which means my user and roles and grant information is not in pg_dump
On the other hand we have pg_dumpall, I read conversation, and this does not lead me anywhere?
Question
- Which one should I be using for database backups? pg_dump or pg_dumpall?
- the requirement is that I can take the backup and should be able to import to any machine and it should work just fine.
The usual process is:
pg_dumpall --globals-only to get users/roles/etc
pg_dump -Fc for each database to get a nice compressed dump suitable for use with pg_restore.
Yes, this kind of sucks. I'd really like to teach pg_dump to embed pg_dumpall output into -Fc dumps, but right now unfortunately it doesn't know how so you have to do it yourself.
Up until PostgreSQL 11 there was also a nasty caveat with this approach: Neither pg_dump, nor pg_dumpall in --globals-only mode would dump user access GRANTs on DATABASEs. So you pretty much had to extract them from the catalogs or filter a pg_dumpall. This is fixed in PostgreSQL 11; see the release notes.
Make pg_dump dump the properties of a database, not just its contents (Haribabu Kommi)
Previously, attributes of the database itself, such as database-level GRANT/REVOKE permissions and ALTER DATABASE SET variable settings, were only dumped by pg_dumpall. Now pg_dump --create and pg_restore --create will restore these database properties in addition to the objects within the database. pg_dumpall -g now only dumps role- and tablespace-related attributes. pg_dumpall's complete output (without -g) is unchanged.
You should also know about physical backups - pg_basebackup, PgBarman and WAL archiving, PITR, etc. These offer much "finer grained" recovery, down to the minute or individual transaction. The downside is that they take up more space, are only restoreable to the same PostgreSQL version on the same platform, and back up all tables in all databases with no ability to exclude anything.
We are using pg_dumpall to make backups of our psql database. We have user with superuser rights that runs pg_dumpall. Everything works fine.
The thing that in my opinin can be better is to limit that users rights (just in case).
So, my question is - can we create some user without superuser rights but with the rigtes to use pg_dumpall corretly?
Dumping database roles and their passwords will be a problem anyway. You could create a role that has SELECT-permissions on all databases and system tables, but then you have the same security issues as you will have with a superuser: passwords (or hashes) and all data can be retrieved.
I would use a superuser for making backups, it's his job anyway.