Обсуждение: Re: BUG #3245: PANIC: failed to re-find shared lock object

Поиск
Список
Период
Сортировка

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

От
"Dorochevsky,Michel"
Дата:
> 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: BUG #3245: PANIC: failed to re-find shared lock object

От
Tom Lane
Дата:
"Dorochevsky,Michel" <michel.dorochevsky@softcon.de> 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

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

От
Heikki Linnakangas
Дата:
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