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 do
"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 yoursel
> 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?
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 r
"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-
"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 an
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
