Accidentally restored a another database to the 'postgres' database how to correct - postgresql

I accidentally restored another database as the default postgres database, how do I correct this?
postgres v10 on ubuntu.

To be specific. Log into a database other then postgres.
Then:
DROP DATABASE postgres;
CREATE DATABASE postgres; --You don't need to specify template1 it is the default.
Then do your restore. If you are using pg_restore make sure you use -C to have the database CREATEd properly.

Related

Postgres - required databases

I have accidentally deleted the default "postgres" database from my postgres. I've read that:
Most Postgres servers have three databases defined by default: template0 , template1 and postgres . template0 and template1 are skeleton databases that are or can be used by the CREATE DATABASE command. postgres is the default database you will connect to before you have created any other databases.
I have now created again a postgres database by running CREATE DATABASE postgres.
Do I need to do anything else to basically redo deleting the "postgres" database? Or the current one is basically the same?
Thanks
The database postgres is in no way special. You should use the bootstrap superuser (normally postgres) as the database owner, then the database will be just as good as the original postgres database.
The only difference is that the new database will have an OID ≥ 16384, which identifies it as an object created after cluster initialization. However, a quick look through the source code makes me believe that we don't use that anywhere.

How to recover or recreate orginal Postgres database after dropping it?

I accidentally dropped original postgres database after installing postgreSQL software. Postgres user is still there, \du superuser. How to recover or recreate original postgres database?
https://www.postgresql.org/docs/current/static/sql-createdatabase.html
just run
create database postgres;
it will create db with default template (which is "template1"). If you did not modify it - it will be same is previous "postgres" db
You can only recover it if you have some previous backup of that database, by restoring that backup and then applying WAL files upto the time when drop database statement was issued.
There is no other way to recover a dropped database.

How to rename an Amazon RDS hosted PostgreSQL database

I have restored a snapshot from an existing RDS PostgreSQL database. Now I want to rename that database but can't find how to do it anywhere in the AWS documentation.
Nor can I find how to use the master password (which I expect let's me do it).
Logging in with postgres into template1 database and then ALTER DATABASE foo RENAME TO bar; worked

template0 and template1 database dropped accidently

I did not know that template0 and template1 database templates are required in order to create empty databases. I deleted them in order to clear up postgres. Now I'm not able to create any new database. Gives me this error :
ERROR: template database "template1" does not exist
What can I do to get things going once again. I'll be very thankful for any help.
Luckily I had postgres database preserved because it was required for the postgres user to log into psql. Thus, created a template0 and template1 database :
create database template0 TEMPLATE postgres;
and same for template1. Then executed :
update pg_database set datistemplate=true where datname='template0';
for both databases to stop myself from accidentally deleting these templates again.
Everything works fine now :)
On my CentOS 7 box, I was not so lucky as to still have a database to connect to. However:
su postgres -c "initdb /var/lib/pgsql/data"
(as root) created a template0 and template 1 to work with.
For postgres 12.3 the following worked for me.
I deleted template1 not knowing what it was. I was able to create it from template0. You could also create it from postgres.
createdb -T template0 template1
createdb -T postgres template1
This is suggested in the docs -
template1 and template0 do not have any special status beyond the fact that the name template1 is the default source database name for CREATE DATABASE. For example, one could drop template1 and recreate it from template0 without any ill effects.
https://www.postgresql.org/docs/current/manage-ag-templatedbs.html
on my debian machine, i upgraded some clusters to version 11.
the template[01] databases on the target cluster have been dropped, rendering me with the ones from the older versions.
as root, i created a new cluster with pg_createcluster.
as user postgres:
dump the databases of the new cluster with pg_dumpall (with the --clean flag).
drop the new cluster.
import the resulted source in your cluster with psql.
i would remove the drop role postgres and creation of the same.
best regards,
alex

pg_dump vs pg_dumpall? which one to use to database backups?

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.