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