pgsql: pg_upgrade: Preserve database OIDs. - Mailing list pgsql-committers

From Robert Haas
Subject pgsql: pg_upgrade: Preserve database OIDs.
Date
Msg-id E1nC5FX-0001DZ-AT@gemulon.postgresql.org
Whole thread Raw
List pgsql-committers
pg_upgrade: Preserve database OIDs.

Commit 9a974cbcba005256a19991203583a94b4f9a21a9 arranged to preserve
relfilenodes and tablespace OIDs. For similar reasons, also arrange
to preserve database OIDs.

One problem is that, up until now, the OIDs assigned to the template0
and postgres databases have not been fixed. This could be a problem
when upgrading, because pg_upgrade might try to migrate a database
from the old cluster to the new cluster while keeping the OID and find
a different database with that OID, resulting in a failure. If it finds
a database with the same name and the same OID that's OK: it will be
dropped and recreated. But the same OID and a different name is a
problem.

To prevent that, fix the OIDs for postgres and template0 to specific
values less than 16384. To avoid running afoul of this rule, these
values should not be changed in future releases. It's not a problem
that these OIDs aren't fixed in existing releases, because the OIDs
that we're assigning here weren't used for either of these databases
in any previous release. Thus, there's no chance that an upgrade of
a cluster from any previous release will collide with the OIDs we're
assigning here. And going forward, the OIDs will always be fixed, so
the only potential collision is with a system database having the
same name and the same OID, which is OK.

This patch lets users assign a specific OID to a database as well,
provided however that it can't be less than 16384. I (rhaas) thought
it might be better not to expose this capability to users, but the
consensus was otherwise, so the syntax is documented. Letting users
assign OIDs below 16384 would not be OK, though, because a
user-created database with a low-numbered OID might collide with a
system-created database in a future release. We therefore prohibit
that.

Shruthi KC, based on an earlier patch from Antonin Houska, reviewed
and with some adjustments by me.

Discussion: http://postgr.es/m/CA+TgmoYgTwYcUmB=e8+hRHOFA0kkS6Kde85+UNdon6q7bt1niQ@mail.gmail.com
Discussion: http://postgr.es/m/CAASxf_Mnwm1Dh2vd5FAhVX6S1nwNSZUB1z12VddYtM++H2+p7w@mail.gmail.com

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/aa01051418f10afbdfa781b8dc109615ca785ff9

Modified Files
--------------
doc/src/sgml/ref/create_database.sgml | 18 ++++++++++-
src/backend/commands/dbcommands.c     | 57 ++++++++++++++++++++++++++++++++---
src/bin/initdb/initdb.c               | 22 ++++++++++++--
src/bin/pg_dump/pg_dump.c             | 12 ++++++--
src/bin/pg_upgrade/IMPLEMENTATION     |  2 +-
src/bin/pg_upgrade/info.c             |  9 ++----
src/bin/pg_upgrade/pg_upgrade.h       |  3 +-
src/bin/pg_upgrade/relfilenode.c      |  4 +--
src/bin/psql/tab-complete.c           |  2 +-
src/include/access/transam.h          |  4 +++
src/include/catalog/unused_oids       |  9 ++++++
11 files changed, 120 insertions(+), 22 deletions(-)


pgsql-committers by date:

Previous
From: Andrew Dunstan
Date:
Subject: pgsql: Unbreak pg_basebackup/t/010_pg_basebackup.pl on msys
Next
From: Robert Haas
Date:
Subject: pgsql: Server-side gzip compression.