Re: Getting rid of duplicate tables.

Jared Carr <jared(at)89glass(dot)com> writes:
> Tom Lane wrote:
>> 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 (dot)(dot)(dot)(dot)D(dot)(dot)DP(dot)(dot)(dot)(dot)(at)(dot)@

> 39BFC = 0

[ blinks... ] Hm, no need to check the bit direction on that one.
Zero means that the transaction was never recorded as *either* committed
or aborted. Which is certainly not the state that whoever marked (27,2)
saw. So what we've got here apparently is active loss of transaction
commit bits :-(.

Can you tell whether you had any backend crashes on 29 December?
It's barely possible that the transaction really did crash and this
status is correct, in which case we have only a read failure to explain
rather than an after-the-fact change in recorded transaction status ...

regards, tom lane