Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce)

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>
To: Shruthi Gowda <gowdashru@gmail.com>
Cc: Julien Rouhaud <rjuju123@gmail.com>, Sadhuprasad Patro <b.sadhu@gmail.com>, Stephen Frost <sfrost@snowman.net>, Bruce Momjian <bruce@momjian.us>, Andres Freund <andres@anarazel.de>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Masahiko Sawada <sawada.mshk@gmail.com>, Tom Kincaid <tomjohnkincaid@gmail.com>, Amit Kapila <amit.kapila16@gmail.com>, Thomas Munro <thomas.munro@gmail.com>, PostgreSQL Development <pgsql-hackers@postgresql.org>, Masahiko Sawada <masahiko.sawada@2ndquadrant.com>, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2022-01-20T19:38:15Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Rethink method for assigning OIDs to the template0 and postgres DBs.

  2. pg_upgrade: Preserve database OIDs.

  3. pg_upgrade: Preserve relfilenodes and tablespace OIDs.

  4. Fix for new Boolean node

  5. Improve error handling of HMAC computations

  6. Add macro RelationIsPermanent() to report relation permanence

  7. Enhance nbtree index tuple deletion.

On Thu, Jan 20, 2022 at 11:03 AM Shruthi Gowda <gowdashru@gmail.com> wrote:
> It is not required for PostgresObjectId. The unused_oids script
> provides a list of unused oids in the manually-assignable OIDs range
> (1-9999).

Well, so ... why are we not treating the OIDs for these two databases
the same? If there's a range from which we can assign OIDs without
risk of duplication and without needing to update this script, perhaps
we ought to assign both of them from that range and leave the script
alone.

+ * that is in use in the old cluster is also used in th new cluster - and

th -> the.

+preserves the DB, tablespace, relfilenode OIDs so TOAST and other references

Insert "and" before "relfilenode".

I think this is in pretty good shape now.

-- 
Robert Haas
EDB: http://www.enterprisedb.com