aboutsummaryrefslogtreecommitdiff
path: root/src/backend/access/gist/gistscan.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2009-06-05 18:50:59 +0000
committerTom Lane <tgl@sss.pgh.pa.us>2009-06-05 18:50:59 +0000
commitf5f3d1440a6f152859d601ee3c9230835d0dcc4f (patch)
tree8f83633c72ab7c380fc190567723a40ddbbf4e86 /src/backend/access/gist/gistscan.c
parent7920e7cc7fa4bc8b95a72c251bcac56537bfa699 (diff)
downloadpostgresql-f5f3d1440a6f152859d601ee3c9230835d0dcc4f.tar.gz
postgresql-f5f3d1440a6f152859d601ee3c9230835d0dcc4f.zip
GIN's ItemPointerIsMin, ItemPointerIsMax, and ItemPointerIsLossyPage macros
should use GinItemPointerGetBlockNumber/GinItemPointerGetOffsetNumber, not ItemPointerGetBlockNumber/ItemPointerGetOffsetNumber, because the latter will Assert() on ip_posid == 0, ie a "Min" pointer. (Thus, ItemPointerIsMin has never worked at all, but it seems unused at present.) I'm not certain that the case can occur in normal functioning, but it's blowing up on me while investigating Tatsuo-san's data corruption problem. In any case it seems like a problem waiting to bite someone. Back-patch just in case this really is a problem for somebody in the field.
Diffstat (limited to 'src/backend/access/gist/gistscan.c')
0 files changed, 0 insertions, 0 deletions