Low Object IDs（OID）在PostgreSQL中有着特殊的含义，但其边界与您想象的不同。0x6000在PostgreSQL中没有特殊的含义。
引用src/include/access/transam.h的相关部分可以最好地解释这一点：

/* ----------
 *      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

所以：

• 10000以下的OID是固定的，并且对某些对象进行了硬编码
• 12000以下的OID是不能删除的系统对象（public架构和数据库除外）
• 16384下的OID是系统对象
• OID生成器为用户对象分配更高的编号

另请参阅有关该主题的文档。