aboutsummaryrefslogtreecommitdiff
path: root/src/backend/access/gist/gistvacuum.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2009-06-05 18:50:47 +0000
committerTom Lane <tgl@sss.pgh.pa.us>2009-06-05 18:50:47 +0000
commit52f0fc703f024555b58eac3dbf08c3a78de13263 (patch)
tree0256756283ae89dfdd740a20244425c55c9a82b5 /src/backend/access/gist/gistvacuum.c
parent8b78428fc0a6079e5ca8d0e9b50375bd0439e351 (diff)
downloadpostgresql-52f0fc703f024555b58eac3dbf08c3a78de13263.tar.gz
postgresql-52f0fc703f024555b58eac3dbf08c3a78de13263.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/gistvacuum.c')
0 files changed, 0 insertions, 0 deletions