Heikki Linnakangas <hlinnakangas@vmware.com> writes:
> ISTM the "correct" fix would be to define a gbtreekey12 data type and
> use that. That's not back-patchable though, and introducing a whole new
> type to save a few bytes is hardly worth it. What you did makes sense.
BTW, the *real* problem with all this stuff is that the gbtreekeyNN types
are declared as having int alignment, even though some of the opclasses
store double-aligned types in them. I imagine it's possible to provoke
bus errors on machines that are picky about alignment. The first column
of an index is safe enough because index tuples will be double-aligned
anyway, but it seems like there's a hazard for lower-order columns.
This is something we cannot fix compatibly :-(
regards, tom lane