Re: Getting rid of duplicate tables.

Jared Carr <jared(at)89glass(dot)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.

I'm off to take a real close look at what was done to the pg_clog code
during the 7.4 cycle ...

regards, tom lane