> "Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu> writes:
>> But not sure why it reports the following error
>> message (which looks like a post-commit cleanup caused error):
>
>> DEBUG: AbortCurrentTransaction
>> PANIC: cannot abort transaction 14135438, it was already committed
>
> I think this is an artifact of the fact that VACUUM FULL commits its own
> transaction before it starts the final index cleanup pass. We ought to
> think of a better way to handle that sometime. I don't recall having
> seen a PANIC like this reported before, but on reflection it seems like
> this would be guaranteed to happen for any ERROR condition occurring
> during that last pass. An error there would be pretty improbable, but
> surely not impossible.
>
>
>>>I have check my past postgresql log file, i did not see this error come
>>>out (i did vacuum full every night).
>
>
> As for the OP's problem, it seems pretty suspicious that we got through
> one cycle of vacuuming pg_class_relname_nsp_index and then the second
> one failed with what seems to be a bad block link. If that bad link was
> there before, why didn't it fail the first time through? I'm wondering
> about flaky hardware ...
>
>>>Any tool to check am i having a flaky hardware?
>>>
>>>Regards
>>>Beh