Re: Getting rid of duplicate tables.

Tom Lane wrote:

>Jared Carr <jared@89glass.com> writes:
>
>
>> 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.
>
>
Here is the appropriate "line" (line is used *very* loosely there)

00039BF0  04 10 00 00 44 00 14 44 50 00 10 01 00 40 04 40 ....D..DP....@.@

39BFC = 0

Jared Carr