Início / dba / Perguntas / 316723
Accepted
MacGyver
Asked: 2022-09-10 13:23:49 +0800 CST

Faixas de lançamento do OID para objetos de banco de dados integrados (também conhecidos como padrão) durante a instalação do PostgreSQL

  • 772

O software normalmente reserva intervalos de lançamento de id para identificadores de objetos padrão (o PostgreSQL chama esses objetos 'internos') para objetos criados durante uma instalação ou patch/upgrade. Estou tendo dificuldade em encontrar os intervalos de lançamento do OID para objetos PostgreSQL. Alguém pode me indicar a documentação para isso? Além disso, os OIDs estão sendo eliminados do PostgreSQL? Como isso afetará minha(s) pergunta(s)?

Como exemplo, a tabela pg_roles parece usar OIDs de quatro dígitos ou menos para objetos criados durante a instalação ou para patches, mas a documentação é limitada. Essa foi a coisa mais próxima que encontrei.

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

Os patches que atribuem manualmente OIDs para novos objetos integrados (como novas funções) agora devem escolher aleatoriamente OIDs no intervalo de 8000 a 9999. No final de um ciclo de desenvolvimento, os OIDs usados ​​pelos patches confirmados serão renumerados para números menores, atualmente em algum lugar na faixa de 4xxx, usando o novo script renumber_oids.pl. Essa abordagem deve reduzir bastante as chances de colisões de OID entre diferentes patches em processo.

Embora não haja uma política específica reservando quaisquer OIDs para uso externo, é recomendado que bifurcações e outros projetos que precisem de OIDs privados atribuídos manualmente usem números na faixa alta de 7xxx. Isso evitará conflitos com patches recentemente mesclados e deve levar muito tempo até que o projeto principal atinja esse intervalo.

E dada a citação acima, talvez uma maneira melhor de fazer a pergunta seja "Qual é o valor da semente OID ou o algoritmo OID usado para a criação de novos objetos de cada tipo (ou seja: pg_roles)?"

Embora não haja uma política específica reservando quaisquer OIDs para uso externo

postgresql

1 respostas

  1. Best Answer

    O intervalo de OIDs para objetos do sistema 1é 16383.

    Nos arquivos include do PostgreSQL, server/access/transam.htem esta apresentação de como os OIDs são atribuídos, o que pode ajudar:

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

    Se você precisasse de seus próprios OIDs no intervalo do sistema por algum motivo, acho que se enquadraria na categoria "fork", portanto, no 8000-9999intervalo.

    P: Além disso, os OIDs estão sendo eliminados do PostgreSQL?

    Não, mas as colunas OID foram rebaixadas para colunas "normais" no Postgres 12, em oposição às colunas do sistema. Houve um processo gradual na evolução do Postgres para normalizar os OIDs como chaves primárias numéricas normais por tabela, em vez da "chave primária globalmente exclusiva" que eles eram no design original. Veja, por exemplo, a postagem do blog OIDs rebaixados para colunas normais: um olhar sobre o passado sobre essa evolução. Isso não é para eliminar os OIDs, mas para garantir que eles não atrapalhem o progresso.

    P: Como exemplo, a tabela pg_roles parece usar OIDs de quatro dígitos ou menos para objetos criados durante a instalação ou para patches

    pg_rolesem si não é uma tabela, é uma visão. Uma de suas colunas é denominada oid, e seu valor vem de pg_authid.oid. É a chave primária do pg_authid. Não há realmente nada nisso que tenha muito a ver com a instalação, exceto que a função do sistema criada (geralmente postgres) tem um oidvalor abaixo 16384, e as funções criadas após a instalação com CREATE USERou CREATE ROLEterão oidvalores acima 16384.

    • 2

relate perguntas