aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2016-09-03 13:28:53 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2016-09-03 13:28:53 -0400
commit36646d3aff0cf6ff9f26033e38808d23e27426e8 (patch)
tree8f720e23c6e4f2f20e41b525a3bef4fa1dae35ca
parent33befe035d86d833a5bc7289612722a4e650227d (diff)
downloadpostgresql-36646d3aff0cf6ff9f26033e38808d23e27426e8.tar.gz
postgresql-36646d3aff0cf6ff9f26033e38808d23e27426e8.zip
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.15676.7628@wrigleys.postgresql.org> Possible-Report: <2DA7350F7296B2A142272901@eje.land.credativ.lan>
-rw-r--r--src/backend/access/gin/gindatapage.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/src/backend/access/gin/gindatapage.c b/src/backend/access/gin/gindatapage.c
index 97c8bf78e7e..276376a6f1d 100644
--- 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