BUG #3245: PANIC: failed to re-find shared lock object

Lists: pgsql-bugs
From: "Michel Dorochevsky" <Michel(dot)Dorochevsky(at)softcon(dot)de>
To: pgsql-bugs(at)postgresql(dot)org
Subject: BUG #3245: PANIC: failed to re-find shared lock object
Date: 2007-04-19 18:27:07
Message-ID: 200704191827.l3JIR7eK004919@wwwmaster.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-bugs


The following bug has been logged online:

Bug reference: 3245
Logged by: Michel Dorochevsky
Email address: Michel(dot)Dorochevsky(at)softcon(dot)de
PostgreSQL version: 8.2.3
Operating system: Windows 2000 / XP / 2003
Description: PANIC: failed to re-find shared lock object
Details:

We are using "PostgreSQL 8.2.3 on i686-pc-mingw32, compiled by GCC gcc.exe
(GCC) 3.4.2 (mingw-special)"

We are encountering the following problem:
>> start extract from the log files in pg_log <<
2007-04-19 15:52:29 LOG: database system is ready
2007-04-19 16:22:19 PANIC: failed to re-find shared lock object
2007-04-19 16:22:19 STATEMENT: COMMIT PREPARED
'257_bG9naWRyZWYvMTU4MwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAA==_MQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAA=='

This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.
2007-04-19 16:22:19 LOG: server process (PID 20184) exited with exit code
3
2007-04-19 16:22:19 LOG: terminating any other active server processes
>> end extract from the log files in pg_log <<

Our log_error_verbosity is set to verbose.

We are experiencing this problem on different Windows platforms: Windows
2000 Professional, XP and XP Server 2003 (with the latest service packs) on
Intel.

We have reinstalled the database from scratch several times.

Our application accesses the database through the JDBC driver included in
the PostgreSQL distribution. It is a complex application
(JBoss/Hibernate/2-Phase-Commit) where it is difficult to provide a consise
test routine to reproduce the problem. We can reproduce this problem almost
deterministically with a test suite 2 times of 3 runs, but still with all
the JBoss/Hibernate/... environment.

My question is: how could we proceed to get help?
Does any one know of a clever way to record the JDBC statements (including
the bind parameters) in order have a strpped down test routine?

Best Regards

Michel
SOFTCON-IT Service GmbH


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Michel Dorochevsky" <Michel(dot)Dorochevsky(at)softcon(dot)de>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #3245: PANIC: failed to re-find shared lock object
Date: 2007-04-19 20:36:13
Message-ID: 14257.1177014973@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-bugs

"Michel Dorochevsky" <Michel(dot)Dorochevsky(at)softcon(dot)de> writes:
> We are encountering the following problem:
> 2007-04-19 16:22:19 PANIC: failed to re-find shared lock object
> 2007-04-19 16:22:19 STATEMENT: COMMIT PREPARED

Wow, that's interesting.

> My question is: how could we proceed to get help?
> Does any one know of a clever way to record the JDBC statements (including
> the bind parameters) in order have a strpped down test routine?

In 8.2 the regular query logging facility (log_statement = ALL) should
be enough. I don't know of any real simple way to feed the log output
back into the system for testing, though.

Another thing that would be interesting is to keep an eye on the
pg_locks view. There's no way to tell from this message whether the
COMMIT is somehow failing to find a lock entry that does exist in the
table, or whether someone else managed to remove the lock entry between
PREPARE and COMMIT; but perhaps you could find out from watching the
pg_locks entries for prepared transactions.

regards, tom lane