Re: pgsql: Fix gratuitous error message variation

Em sáb., 9 de nov. de 2019 às 05:02, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> escreveu:
>
> On 2019-11-09 02:20, Tom Lane wrote:
> > Peter Eisentraut <peter@eisentraut.org> writes:
> >> Fix gratuitous error message variation
> >
> > Hm, as long as you're touching that ... OIDs should be formatted
> > with %u not %d.
>
> This is just a fixup of the recent patch
> 8f75e8e44609335e6bdd73123284682235f242a2.
>
> Replication origin IDs are actually
>
> typedef uint16 RepOriginId;
>
... that is different from OIDs.

> so using the term OID is probably wrong altogether.  I'm not sure what
> the overall intent was here.
>
According to the following comment:

     * We need the numeric replication origin to be 16bit wide, so we cannot
     * rely on the normal oid allocation. Instead we simply scan
     * pg_replication_origin for the first unused id. That's not particularly
     * efficient, but this should be a fairly infrequent operation - we can
     * easily spend a bit more code on this when it turns out it needs to be
     * faster.

... it seems the author wants to use OID infrastructure for a type
(RepOriginId) that is similar to Oid.

Although, it is a different representation from OID, it uses OID
infrastructure in its API. Indeed RepOriginId is a subset of Oid. If
terminology "replication origin OID" is used, users can complain that
it will fail to allocate more than 65k replication origins (OID range
is much larger).Frankly, I don't foresee it happen in decades. I think
"replication origin" shouldn't use OID datatype, however, that ship
has sailed. I propose to use %u instead of %d (same as we do with
OIDs). I also included a s/oid/OID/. Patch is attached.


--
   Euler Taveira                                   Timbira -
http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento