I have just found a nasty portability problem in the new statistics
stuff. It assumes that it can store int64 values in hashtable entries
... but the dynahash module hands back pointers that are only aligned
to sizeof(long). On a machine where int64 has to be 8-byte-aligned,
instant coredump.
I hadn't noticed this before, even though HPPA is just such an
architecture, because gcc emits pairs of single-word load and store
instructions for int64, not doubleword load and store. As soon as
I recompiled with HP's compiler, pgstat didn't work anymore.
I think the cleanest answer is to fix dynahash so that it gives back
MAXALIGN'd pointers. It looks like this will not waste a significant
amount of space, and it'll probably be a necessary change in the long
run anyway.
While I'm messing with this, I think I will also change the API for
hash_create so that one specifies the key size and the total entry
size, not the key size and data size to be added together. It's
too easy to get the alignment considerations wrong with the present
API --- there are a number of places that are presently silently
assuming that there's no padding in their hashtable entry structs,
eg ri_triggers.c. And I observe that pgstat itself thinks that that's
what the API is anyway...
Comments, objections? I think this is a must-fix-before-beta item.
regards, tom lane
