So I tried using pg_visibility's pg_check_visible() as part of
testing the business with pg_upgrade generating faulty visibility
maps on bigendian servers, and it instantly generated an assert
failure here:
#2 0x0041de78 in ExceptionalCondition (conditionName=<value temporarily
unavailable, due to optimizations>, errorType=<value temporarily unavailable,
due to optimizations>, fileName=<value temporarily unavailable, due to
optimizations>, lineNumber=<value temporarily unavailable, due to
optimizations>) at assert.c:54
#3 0x0045c410 in HeapTupleSatisfiesVacuum (htup=0x0, OldestXmin=9170,
buffer=2958) at tqual.c:1169
#4 0x00a41c3c in tuple_all_visible (tup=0xbfffd8e4, OldestXmin=9170,
buffer=<value temporarily unavailable, due to optimizations>) at
pg_visibility.c:719
#5 0x00a420a8 in collect_corrupt_items (relid=46802, all_visible=<value
temporarily unavailable, due to optimizations>, all_frozen=<value temporarily
unavailable, due to optimizations>) at pg_visibility.c:630
#6 0x00a4262c in pg_check_visible (fcinfo=0x104b704) at pg_visibility.c:328
The problem seems to be that HeapTupleSatisfiesVacuum asserts
Assert(ItemPointerIsValid(&htup->t_self));
while collect_corrupt_items hasn't bothered to set up the t_self
field of the HeapTupleData it's passing in. This would imply that
you never tested this code in an assert-enabled build, which I find
surprising. Am I missing something?
(I'm not really sure *why* HeapTupleSatisfiesVacuum contains this
Assert, because it doesn't do anything with t_self, but nonetheless
the Assert has been there for several years. Seems to have been
inserted by you, in fact.)
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
