btoidsortsupport issue

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Cc: John Naylor <johncnaylorls(at)gmail(dot)com>
Subject: btoidsortsupport issue
Date: 2026-08-09 20:19:02
Message-ID: CAH2-WznvXyKRah=MQ3ONGHiN8ahJcqpmtyikxCOO96A4usDPpg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I had Opus 5 look for bugs in recent Postgres commits. It authored the
test case added by the attached patch. The test fails for me on master
after commit 51cd5d6f:

# ORDER BY f1;
# f1
# ------------
# 5
# 10
# 15
# 987
# 1234
# 1235
# 99999999
# - 4294966256
# 4294967000
# + 4294966256
# (9 rows)

btoidsortsupport() uses ssup_datum_unsigned_cmp() at that commit,
which compares all 64 bits of each Datum. The test case shows that the
same oid value can reach the comparator with the extraneous bits
filled two different ways. Tuple deformation sign-extends every 4-byte
pass-by-value attribute (see fetch_att() and friends), whereas
ObjectIdGetDatum() zero-extends instead. This inconsistency makes
their datums incompatible for ssup_datum_unsigned_cmp's purposes,
leading to wrong answers in certain narrow cases.

--
Peter Geoghegan

Attachment Content-Type Size
0001-Add-test-showing-oid-sort-support-mis-orders-values-.patch application/octet-stream 2.0 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2026-08-09 21:06:54 Re: btoidsortsupport issue
Previous Message Tom Lane 2026-08-09 19:03:57 Re: 2026-08-13 release announcement draft