Re: [BUGS] BUG #3245: PANIC: failed to re-find shared lock object
Tom Lane wrote I've committed a fix for this; it'll be in the next set of releases. regards, tom lane Tom, Thanks a lot for all your work and help, I am very impressed by the PostgreSQL Team. Just a last question. Are you planning to provide a binary fix for 8.2.x? What would be the time frame we could expoect? I guess the fix is not yet included in the 8.2.4 release (though I read Fix PANIC during enlargement of a hash index (Tom))? Best Regards -- Michel
Re: [BUGS] BUG #3245: PANIC: failed to re-find shared lock object
Dorochevsky,Michel [EMAIL PROTECTED] writes: Are you planning to provide a binary fix for 8.2.x? I personally am not --- IIRC you are running on Windows, which I don't even have a build environment for. But you could pull REL8_2_STABLE branch tip from the CVS server and build it for yourself, or get someone else to do it for you. As for when it will appear in an official release, I'd imagine the next 8.2 update will be in a couple months. I thought a bit about whether we ought to force a release for this particular bug, but couldn't really justify it -- the overhead of a release is enormous, and seeing that nobody had hit this bug in the more-than-a-year since 8.1 was released, it's hard to argue that it's worth it. I'm still not very sure why you're hitting the problem more often than other people. There might be some tweak you could make in your application code to dodge the issue. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #3245: PANIC: failed to re-find shared lock object
Tom Lane wrote: I'm still not very sure why you're hitting the problem more often than other people. There might be some tweak you could make in your application code to dodge the issue. The initial size of the local lock hash table is 128. That's a lot of locks, most applications probably don't use that many locks and therefore avoid the issue. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] BUG #3245: PANIC: failed to re-find shared lock object
I wrote: Also, we have a generic issue that making fresh entries in a hashtable might result in a concurrent hash_seq_search scan visiting existing entries more than once; that's definitely not something any of the existing callers are thinking about. I'm too tired to think about fixes right now, but we've definitely found a hotbed of actual and potential bugs. I've committed a fix for this; it'll be in the next set of releases. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #3245: PANIC: failed to re-find shared lock object
Dorochevsky,Michel [EMAIL PROTECTED] writes: Two runs of the same test program fail at different places, so it seems to be dependent of the timing. Two log files are available at www.dorochevsky.de/infos/postgresql-2007-04-20_145638.zip www.dorochevsky.de/infos/postgresql-2007-04-20_144006.zip Hm, could you try again with log_line_prefix set to '%m %p ' rather than just %t? It's too hard to guess which messages are coming from which backend ... regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[BUGS] BUG #3245: PANIC: failed to re-find shared lock object
The following bug has been logged online: Bug reference: 3245 Logged by: Michel Dorochevsky Email address: [EMAIL PROTECTED] 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_bG9naWRyZWYvMTU4MwA AAA==_MQ ==' 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 ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [BUGS] BUG #3245: PANIC: failed to re-find shared lock object
Michel Dorochevsky [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
