Created a Postgres plain text SQL file using pg_dump. When importing the text SQL file using the psql -f everything seems to be running fine.
But the newly imported databases is missing the search_path. The source database has the search_path, I expected the destination database to have the same. Looking at the plain SQL file in an editor I see the SET search_path command. So is this an issue or am I missing something?
The search_path is set per session and can be changed any time. You can store presets for a database, a role or even a role in a particular database. That would be set with commands like:
ALTER DATABASE test SET search_path = blarg,public;
ALTER ROLE foo SET search_path = blarg,public;
Etc.
Or maybe you want a general setting in postgresql.conf to begin with? See link below.
A plain:
SET search_path = blarg,public;
like you see in SQL file only sets a search_path for the session it is executed in.
The underlying issue may be this (quoting the manual):
Database roles are global across a database cluster installation (and
not per individual database).
Bold emphasis mine.
A backup of a database with pg_dump (not the whole cluster with pg_dumpall, not including global objects), does not include roles. If you have set a default search_path for a role, then that is not included.
Details:
How does the search_path influence identifier resolution and the "current schema"
Setting of search_path does not appear in the pg_dump's output even if set on database level, ie. by command
ALTER DATABASE XXX set search_path to aaa, bbb, ccc;
Then, after dumping and restoring the database with pg_dump/pg_restore, the restored database does not have the search_path set, ie. the one coming from source template stays active in the restored database.
Tested with version 13.7.
It is also discussed here PG-mail-list and David J. explains it, but I consider it a bug in pg_dump (or better called: design flaw). All per-database settings should appear in the dump, imho.
Related
One of several databases in a Postgres 10.15 cluster has been set to be a system database. The mechanism that caused this is unknown, though it may have happened at the same time that the database was converted to a template by updating the pg_database table. The pg_database table does not have a setting to control whether or not a database is a system database, however, and I cannot find any documentation describing how to set (or unset, which is what I really want to do) the system database flag.
The idea of a “system database” is foreign to PostgreSQL, it is an artifact of pgAdmin.
PostgreSQL does have the notion of a “template database”, that is a database that is intended to serve s template in CREATE DATABASE. You turn a database to a template database with
ALTER DATABASE some_db IS_TEMPLATE TRUE;
For such a database it is also a good idea to forbid connections, because you can only use a database as template if nobody else is connected to it:
ALTER DATABASE some_db ALLOW_CONNECTIONS FALSE;
Given a database dump how to specify a tablespace to be used by all tables during restore? The database has multiple tablespaces used by its table. Old tablespaces should be ignored (they are not relevant on new computer) and all tablespaces my by replaced by a new one.
dump with "--no-tablespaces" parameter to have tablespaces-free dump - but you can also use the same parameter on pg_restore if you cannot change dump commands
set global parameter "default_tablespace" on target DB to what is needed for restore (for example by using alter database xxxxx set DEFAULT_TABLESPACE='xxx')
run all pg_restore tasks
if necessary reset default_tablespace to original value
I have a funny question about PostgreSQL database: What happens if the postgres database is dropped?
dropdb postgres worked.
createdb postgres worked too.
psql worked.
But I thought the users would be lost. Yet the old users are still there.
So where are the users stored for the database and which implications does dropping the postgres database have?
PostgreSQL metadata are stored in catalog tables, which are in the pg_catalog schema. These are accessible like regular views and tables.
There are shared system catalog tables which are shared between all databases. These tables are not affected when databases are dropped.
pg_authid, the table where the users are stored, is one of those shared catalogs. This is because in PostgreSQL, users don't belong to a database, but to the whole database cluster.
You can list all shared catalog tables like this:
SELECT relname FROM pg_class
WHERE relisshared AND relkind = 'r';
In the documentation you can find more information about the system catalogs.
When connecting to a Postgres server, you always need to specify which database you want to connect to.
When you set up a new server, you need something to connect to before you can run your first CREATE DATABASE statement.
That's all the postgres database is: a dummy database to use as a connection target for admin commands. There's no data in there, and you're free to drop it and use a different one instead (though whoever inherits your system will probably not thank you for it...).
As gil.fernandes said in his answer, server-wide objects like users are accessible from every database, but aren't stored inside any database in particular.
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.
What are the default databases in PostgreSQL at the time of installation?
template1: the "default" database, which is copied when you perform "create database foo"
template0: the "minimal default" database, which serves essentially the same purpose, but typically used to create databases when restoring dumps which might already have the extra objects that are in template1, or to create a database that uses a different character encoding to the server default (template0 should only contain ASCII characters in strings)
postgres: an "administrative" database, which clients can assume exists to connect to merely to list which databases are available etc. Also, for example, pgAdmin will install the pg_agent schema in this database.
Apparently there is a database "postgres" that is created by default on each postgresql server installation.
It appears that it does not really have a well-defined purpose. According to the docs:
Creating a database cluster consists of creating the directories in
which the database data will live, generating the shared catalog
tables (tables that belong to the whole cluster rather than to any
particular database), and creating the template1 and postgres
databases. When you later create a new database, everything in the
template1 database is copied. (Therefore, anything installed in
template1 is automatically copied into each database created later.)
The postgres database is a default database meant for use by users,
utilities and third party applications.
(Source: http://www.postgresql.org/docs/8.2/static/app-initdb.html )