pgsql: Fix gratuitous error message variation
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t215689psql -h localhost -U postgresBuilt from patchset v4 (message #4), July 29, 2026 at 12:53 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t215689_4 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t215689_4 && git checkout t215689_4Patchset v4 (message #4) is on t215689_4
Fix gratuitous error message variation
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/3dcffb381c81c9c8f8254100feacac256b9e75a6
Modified Files
--------------
src/backend/replication/logical/origin.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
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.
regards, tom lane
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;
so using the term OID is probably wrong altogether. I'm not sure what
the overall intent was here.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
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