Jared Carr <[EMAIL PROTECTED]> writes:Here is the appropriate "line" (line is used *very* loosely there)
Item 2 -- Length: 148 Offset: 6860 (0x1acc) Flags: USED
XID: min (46034931) CMIN|XMAX: 2 CMAX|XVAC: 0
Block Id: 27 linp Index: 2 Attributes: 23 Size: 28
infomask: 0x2910 (HASOID|XMIN_COMMITTED|XMAX_INVALID|UPDATED)
Item 43 -- Length: 148 Offset: 8044 (0x1f6c) Flags: USED
XID: min (8051642) CMIN|XMAX: 46034931 CMAX|XVAC: 2
Block Id: 27 linp Index: 2 Attributes: 23 Size: 28
infomask: 0x2910 (HASOID|XMIN_COMMITTED|XMAX_INVALID|UPDATED)
Well, there's the smoking gun ... somebody marked (27,2) as XMIN_COMMITTED, showing that they thought 46034931 was committed, while someone else marked (27,43) as XMAX_INVALID, showing that they thought 46034931 was aborted. So we have some kind of very-infrequent breakage in transaction commit-state lookup. Or a hardware problem, but I suspect we are looking at a bug.
Could you check out what pg_clog has for transaction 46034931?
This would be pg_clog/002B (which dates your problem to Dec 29 BTW),
byte at offset 39BFC hex or 236540 decimal. I forget which way the
bits run within the byte but will look it up if you can get me the
value of that byte.
00039BF0 04 10 00 00 44 00 14 44 50 00 10 01 00 40 04 40 [EMAIL PROTECTED]@
39BFC = 0
Jared Carr
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
