Re: BUG #3245: PANIC: failed to re-find shared loc k ob ject
От | Heikki Linnakangas |
---|---|
Тема | Re: BUG #3245: PANIC: failed to re-find shared loc k ob ject |
Дата | |
Msg-id | 462BBB8D.9000005@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: BUG #3245: PANIC: failed to re-find shared loc k ob ject (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #3245: PANIC: failed to re-find shared loc k ob ject
|
Список | pgsql-bugs |
Tom Lane wrote: > "Dorochevsky,Michel" <michel.dorochevsky@softcon.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. Oh, no I wasn't. I'm up to speed now. I can't see any way that can happen either. There's some other transactions running, but not at the time of prepare or commit. And there's no other errors or unusual activity in the logs. The only thing I can think of is that a lock is released between the calls to AtPrepare_Locks and PostPrepare_Locks. But I don't see how that could happen. I think we need to see more debug-information. Is there a debug- and assertion-enabled binary available for Windows? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-bugs по дате отправления: