From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Postmaster cannot start |
Date: | 2006-05-15 14:03:50 |
Message-ID: | 2634.1147701830@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"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.
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 ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Kenneth Downs | 2006-05-15 14:13:45 | Re: GUI Interface |
Previous Message | Qingqing Zhou | 2006-05-15 13:50:19 | Re: Postmaster cannot start |