Re: BUG #3245: PANIC: failed to re-find shared loc k ob ject

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Dorochevsky,Michel" <michel(dot)dorochevsky(at)softcon(dot)de>
Cc: pgsql-bugs(at)postgresql(dot)org, Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
Subject: Re: BUG #3245: PANIC: failed to re-find shared loc k ob ject
Date: 2007-04-22 02:23:30
Message-ID: 16389.1177208610@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

"Dorochevsky,Michel" <michel(dot)dorochevsky(at)softcon(dot)de> writes:
> The failing transaction is visible in the database after restart, I have
> checked three of the last inserts, e.g.

Good, at least we're not losing data ;-). But I expected that because
this PANIC must be occurring after the RecordTransactionCommitPrepared
step.

> I have no leftover file in $PGDATA/pg_twophase, it is empty.

[ digs in code some more... ] Oh, I see how that happens: the 2PC
state file is removed when the XLOG_XACT_COMMIT_PREPARED xlog entry
is replayed, so the various code paths that might emit a warning
won't be reached.

Heikki, have you been paying attention to this thread? You have any
idea what's happening? The whole thing seems pretty unexplainable
to me, especially since Michel's log shows this happening without any
concurrent activity that might confuse matters. I confess bafflement.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Magnus Hagander 2007-04-22 18:52:18 Re: BUG #3242: FATAL: could not unlock semaphore: error code 298
Previous Message Marcin Waldowski 2007-04-21 21:07:08 Re: BUG #3242: FATAL: could not unlock semaphore: error code 298