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
Related
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.
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.
Problem
A simple 2x2 table of data explains my problem. Both databases can be made to work, but they behave differently and I need them to be the same.
PostreSQL Query | Local DB | Amazon-RDS |
--------------------------+------------+-----------------------------------------+
SELECT * from mydb.users; | Success | Success |
--------------------------+------------+-----------------------------------------+
SELECT * from users; | Success | ERROR: relation "users" does not exist |
---------------------------------------------------------------------------------+
Details
The databases should be identical. Amazon-RDS is literally pg_restore'd from a pg_dump of the local database. Exact commands:
$ pg_dump --format=c ---no-privileges --no-owner --verbose \
--host=localhost --port=5432 --username=gary mydb;
$ pg_restore --no-owner --no-tablespaces --dbname=mydb --verbose \
--host=127.0.0.1 --port=47737 \ #ssh tunnel
--username=XXXXXX --format=c
The problem is not with the data dump itself. I've wiped the local database, restored it from the dump, and it still behaves the way it's supposed to.
The problem doesn't just manifest not just with my raw SQL queries, there's a sizable Node/Express app that is supposed to front-end the database. It generates queries without the database prefix in front of the tables too. The app uses Sequelize for an ORM and has been running with MySQL on Amazon-RDS in
production for years. The issue I'm seeing now has only appeared while migrating from MySQL to PostgreSQL.
I have no experience with Postgres.
I don't think it should matter, but in full disclosure, I'm using DBeaver to handle all my database connections, and do the db dump and restore.
Questions
Why does one database successfully infer the database from the name of the table alone, and not the other cannot?
Is there a configuration setting somewhere to make them both work? mydb is the only database in the RDS instance.
mydb is not a database, it's a schema. And it appears that it is not in the schema search_path on RDS.
It could be configured in the cluster settings, the settings of your database, the settings of your (login) user, or locally on the DBeaver connection.
I did a pg_dumpall -c -f <BACKUP_FILE>.sql on a system, I'd like to do a restore on another system and have postgres create all roles/databases/tablespaces for me, is it possible?
This is clearly outlined in the PostgreSQL docs.
https://www.postgresql.org/docs/9.5/static/backup-dump.html
24.1.1. Restoring the Dump
Text files created by pg_dump are intended to be read in by the psql program. The general command form to restore a dump is
psql dbname < infile
where infile is the file output by the pg_dump command. The database dbname will not be created by this command, so you must create it yourself from template0 before executing psql (e.g., with createdb -T template0 dbname). psql supports options similar to pg_dump for specifying the database server to connect to and the user name to use. See the psql reference page for more information. Non-text file dumps are restored using the pg_restore utility.
The issue was that the most recent PE uses postgres 9.4, I could without errors restore to a postgres server running postgres 9.5. My bad, should have checked the rpm's on the PE puppetDB server first.
I search for a while to find this answer but with no luck.
The situation:
I have Postgresql currently running on my production environment. I am preparing to scale my database and move it to a large server instance. I made the mistake of setting up the initial database with the postgres user who has all permissions, and I would like the new database to be controlled by a custom user I have created. ie The current database's owner is postgres, and I want the new database owner to be pooper.
To dump, I am running:
pg_dump -d database_name > database_name.sql
To restore on separate machine, I am running:
psql database_name < database_name.sql
If the user is the same, ie both postgres, then it will work just fine, but when switching users, my app does not load correctly. Is there a secret to the madness. Nothing stood out to me.
My system:
Debian Wheezy
Postgresql 9.1
Postgis Extension
pg_dump with the --no-owner flag (see pg_dump --help)
Create the new db with the new owner CREATE DATABASE foo OWNER pooper;,
Load via psql -U pooper -d database_name -f database_name.sql.