主页 / dba / 问题 / 316723
Accepted
MacGyver
Asked: 2022-09-10 13:23:49 +0800 CST

PostgreSQL 安装期间内置（又名标准）数据库对象的 OID 版本范围

  • 772

软件通常为安装或补丁/升级期间创建的对象的标准对象（PostgreSQL 将这些“内置”对象）的标识符保留 id 发布范围。我很难找到 PostgreSQL 对象的 OID 版本范围。有人可以指出我的文档吗？此外，OID 是否正在逐步退出 PostgreSQL？这将如何影响我的问题？

例如，pg_roles 表似乎对安装期间创建的对象或补丁使用四位数或更少的 OID，但文档有限。这是我能找到的最接近的东西。

https://www.postgresql.org/docs/12/release-12.html

为新的内置对象（例如新函数）手动分配 OID 的补丁现在应该在 8000-9999 范围内随机选择 OID。在开发周期结束时，提交的补丁使用的 OID 将使用新的 renumber_oids.pl 脚本重新编号为较低的数字，目前在 4xxx 范围内。这种方法应该会大大降低不同进程内补丁之间 OID 冲突的几率。

虽然没有保留任何 OID 供外部使用的特定政策，但建议分叉和其他需要私有手动分配 OID 的项目使用高 7xxx 范围内的数字。这将避免与最近合并的补丁发生冲突，并且核心项目应该需要很长时间才能达到该范围。

鉴于上面的引用，也许更好的提问方式是“用于每种类型的新对象创建（即：pg_roles）的 OID 种子值或 OID 算法是什么？”

虽然没有保留任何 OID 供外部使用的具体政策

postgresql

1 个回答

  1. Best Answer

    系统对象的 OID 范围1为16383.

    在 PostgreSQL 包含文件中，server/access/transam.h有关于如何分配 OID 的演示文稿，这可能会有所帮助：

    /* ----------
 *      Object ID (OID) zero is InvalidOid.
 *
 *      OIDs 1-9999 are reserved for manual assignment (see .dat files in
 *      src/include/catalog/).  Of these, 8000-9999 are reserved for
 *      development purposes (such as in-progress patches and forks);
 *      they should not appear in released versions.
 *
 *      OIDs 10000-11999 are reserved for assignment by genbki.pl, for use
 *      when the .dat files in src/include/catalog/ do not specify an OID
 *      for a catalog entry that requires one.  Note that genbki.pl assigns
 *      these OIDs independently in each catalog, so they're not guaranteed
 *      to be globally unique.  Furthermore, the bootstrap backend and
 *      initdb's post-bootstrap processing can also assign OIDs in this range.
 *      The normal OID-generation logic takes care of any OID conflicts that
 *      might arise from that.
 *
 *      OIDs 12000-16383 are reserved for unpinned objects created by initdb's
 *      post-bootstrap processing.  initdb forces the OID generator up to
 *      12000 as soon as it's made the pinned objects it's responsible for.
 *
 *      OIDs beginning at 16384 are assigned from the OID generator
 *      during normal multiuser operation.  (We force the generator up to
 *      16384 as soon as we are in normal operation.)
 *
 * The choices of 8000, 10000 and 12000 are completely arbitrary, and can be
 * moved if we run low on OIDs in any category.  Changing the macros below,
 * and updating relevant documentation (see bki.sgml and RELEASE_CHANGES),
 * should be sufficient to do this.  Moving the 16384 boundary between
 * initdb-assigned OIDs and user-defined objects would be substantially
 * more painful, however, since some user-defined OIDs will appear in
 * on-disk data; such a change would probably break pg_upgrade.
 *
 * NOTE: if the OID generator wraps around, we skip over OIDs 0-16383
 * and resume with 16384.  This minimizes the odds of OID conflict, by not
 * reassigning OIDs that might have been assigned during initdb.  Critically,
 * it also ensures that no user-created object will be considered pinned.
 * ----------
 */
#define FirstGenbkiObjectId     10000
#define FirstUnpinnedObjectId   12000
#define FirstNormalObjectId     16384

    如果您出于某种原因在系统范围内需要自己的 OID，我认为这将属于“分叉”类别，因此在8000-9999范围内。

    问：另外，OID 是否正在从 PostgreSQL 中逐步淘汰？

    不，但是 OID 列在 Postgres 12 中被降级为“普通”列，而不是系统列。在 Postgres 的演变过程中，将 OID 规范化为普通的每个表的数字主键，而不是它们在原始设计中的“全局唯一主键”，这是一个渐进的过程。例如，请参阅博客文章OIDs 降级为普通列：关于这种演变的过去一瞥。这不是要逐步淘汰 OID，而是要确保它们不会妨碍进展。

    问：例如，pg_roles 表似乎对安装期间创建的对象或补丁使用四位或更少的 OID

    pg_roles本身不是一张桌子，它是一个视图。它的一列名为oid，其值来自pg_authid.oid。它是 的主键pg_authid。这实际上与安装没有太大关系，除了创建的系统角色（通常postgres）具有oid低于 的值16384，而安装后创建的角色使用CREATE USERorCREATE ROLE将具有oid高于 的值16384。

    • 2

相关问题