On Wed Jul 29, 2026 at 1:13 PM CDT, PG Bug reporting form wrote:
> The following bug has been logged on the website:
>
> Bug reference: 19587
> Logged by: Michael Malis
> Email address: malis@pgrust.com
> PostgreSQL version: 18.4
> Operating system: Linux x86_64 and Linux aarch64, same package build
> Description:
>
> This is about the internal single-byte "char" type (pg_type oid 18, the
> one needing double quotes), not SQL CHAR(n), which is bpchar and is
> unaffected.
>
> hashchar() and hashcharextended() cast through a bare char, whose
> signedness is implementation-defined:
>
> hashchar(PG_FUNCTION_ARGS)
> { return hash_uint32((int32) PG_GETARG_CHAR(0)); }
>
> DatumGetChar() returns char, so a high-bit byte sign-extends where
> char is signed (x86-64, macOS) and does not where it is unsigned
> (Linux aarch64). Other integer hash functions cast from explicitly-signed
> types and are unaffected.
>
> Reproduce (SQL_ASCII database, on each platform):
>
> SELECT hashchar(chr(128)::"char");
>
> x86-64: 1361043915 (= hashint4(-128))
> aarch64: 1807103465 (= hashint4( 128))
>
> Impact. Hash aggregation and hash joins are unaffected, since a query
> hashes both sides with the same binary. The problem is where the hash is
> persisted: hash partitioning on a "char" column routes rows differently
> per platform, so a pg_dump taken on one architecture fails to restore on
> the other (violates partition constraint; --load-via-partition-root
> avoids it), and a hash index on such a column returns false negatives if
> the data directory is read by a build with the opposite signedness.
Hey Michael,
Thanks for the bug report. I sent a patch[0] to -hackers for review that
should fix this in 19 and above.
[0]: https://www.postgresql.org/message-id/DKBPGEV4AVNC.BRP938ZSVC2L%40partin.io
--
Tristan Partin
PostgreSQL Contributors Team
AWS (https://aws.amazon.com)
