Fix corrupt GIN_SEGMENT_ADDITEMS WAL records on big-endian hardware.

computeLeafRecompressWALData() tried to produce a uint16 WAL log field by
memcpy'ing the first two bytes of an int-sized variable.  That accidentally
works on little-endian hardware, but not at all on big-endian.  Replay then
thinks it's looking at an ADDITEMS action with zero entries, and reads the
first two bytes of the first TID therein as the next segno/action,
typically leading to "unexpected GIN leaf action" errors during replay.
Even if replay failed to crash, the resulting GIN index page would surely
be incorrect.  To fix, just declare the variable as uint16 instead.

Per bug #14295 from Spencer Thomason (much thanks to Spencer for turning
his problem into a self-contained test case).  This likely also explains
a previous report of the same symptom from Bernd Helmle.

Back-patch to 9.4 where the problem was introduced (by commit 14d02f0bb).

Discussion: <20160826072658[email protected]>
Possible-Report: <2DA7350F7296B2A142272901@eje.land.credativ.lan>

diff --git a/src/backend/access/gin/gindatapage.c b/src/backend/access/gin/gindatapage.c
index feac59d9e0d9766d11cfcbc5528d6c7ba8af4f28..93f2d8f350dba96699d7664d5fe87412ff526e25 100644 (file)
--- a/src/backend/access/gin/gindatapage.c
+++ b/src/backend/access/gin/gindatapage.c
@@ -86,7 +86,7 @@ typedef struct
    char        action;
 
    ItemPointerData *modifieditems;
-   int         nmodifieditems;
+   uint16      nmodifieditems;
 
    /*
     * The following fields represent the items in this segment. If 'items' is