So the proposed changes in hash_any make its hash values different
between big-endian and little-endian machines (at least for string keys;
for keys that are really arrays of int, I think the changes will
unify the behavior). This means that the hash_seq_search traversal
order for an internal hash table changes, and it turns out this breaks
at least two regression tests: portals and dblink. The portals test
is easy to fix by adding a couple of ORDER BYs, but the problem with
dblink is here:
SELECT dblink_get_connections();
dblink_get_connections
------------------------
! {dtest1,dtest2,dtest3}
(1 row)
SELECT dblink_is_busy('dtest1');
--- 714,720 ----
SELECT dblink_get_connections();
dblink_get_connections
------------------------
! {dtest1,dtest3,dtest2}
(1 row)
SELECT dblink_is_busy('dtest1');
and right offhand I can't think of a simple way to force those array
elements into a consistent order.
No doubt that can be worked around, but does anyone wish to argue that
this whole thing is a bad path to be headed down? We're not going to
gain a *whole* lot of speedup from the word-wide-hashing change, and
so maybe this type of headache isn't worth the trouble.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
