In order to change the collation of PostgreSQL's database template, I dropped template1 and recreated it with the 'correct' collation. I therefore got my inspiration from this question.
All fine now, but now that newly database template template1 is listed in the available databases in the tree view.
I compared database pg_database for two servers (one listing the database template1, one not), but the values of the parameters for database template1 are the same.
I would like to hide this database from in the tree view.
Anyone who can figure this out?
EDIT: this one did not bring me any further
(PostgreSQL 9.6, pgAdmin 1.22)
PgAdmin uses the following condition to show the database in the tree or not:
/* Condition used to show database */
if (settings->GetShowSystemObjects() || !database->GetSystemObject())
(...)
/* Function called above */
bool pgDatabase::GetSystemObject() const
{
if (server)
{
if (this->GetName() == wxT("template0")) return true;
return (this->GetOid() <= server->GetLastSystemOID());
}
else
{
return false;
}
}
Unless you've marked "Show System Objects in the treeview" option, I guess that your template1's oid is greater than LastSystemOID (pg_database.datlastsysoid). In this case you have three options:
Rebuild your cluster with right collation;
Accept that;
or, assuming you weren't in production, play with
pg_database.datlastsysoid and wait for side effects.
PgAdmin had an issue where template1 was shown even if the option was turned off to show system objects. This happened when you migrated your database before via pg_upgrade.
The image below shows the template database in the current pgAdmin version with the Show system object option enabled:
The issue was in the condition shown by Michel Milezzi. It is not correct to determine that a database is a template by oid <= lastSystemOid. Because when you use pg_upgrade, the oid of the template1 database is changed and the new value is higher than the lastSystemOid (i don't know if this is also a bug).
oid datname datlastsysoid datacl
13394 template0 13394 {=c/postgres,postgres=CTc/postgres}
1 template1 13394 {=c/postgres,postgres=CTc/postgres}
after using pg_upgrade:
13756 template0 13756 {=c/postgres,postgres=CTc/postgres}
16446 template1 13756 {postgres=CTc/postgres,=c/postgres}
^
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;
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.
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.
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
I'm trying to create a new database cluster in postgresql that defaults to LATIN1 encoding, or at least supports it. Does anybody know what locale I could use? I am on Windows 7 64bit
Thanks
I've figured it out with help from a friend. I can use:
English_Sweden.28591
If you want to change the default encoding, you have to create a new template1 database. This database serves as template for creating new databases. Drop the current one and create a new one using template0 and use the correct encoding, latin1 in your case.
UPDATE pg_database
SET datistemplate = false -- otherwise you can't drop this database
WHERE datname = 'template1';
DROP DATABASE template1;
CREATE DATABASE template1 WITH
TEMPLATE template0
ENCODING LATIN1;
Check all settings for template1 before you drop this database, maybe you want these in your new template1 as well.