Re: [HACKERS] Open 6.5 items

Bruce Momjian <maillist@candle.pha.pa.us> writes:
> Folks, do we have anything to revisit here?

I believe it is fixed --- I went back and found some more bugs in
dynahash.c after seeing Tatsuo's report ;-)
        regards, tom lane


>> Tatsuo Ishii wrote:
>>>> 
>>>> I have just done cvs update and saw your changes. I tried the same
>>>> testing as I did before (64 conccurrent connections, and each
>>>> connection excutes 100 transactions), but it failed again.
>>>> 
>>>> (1) without -B 1024, it failed: out of free buffers: time to abort!
>>>> 
>>>> (2) with -B 1024, it went into stuck spin lock
>>>> 
>>>> So I looked into sources a little bit, and made a minor change to
>>>> include/storage/lock.h:
>>>> 
>>>> #define INIT_TABLE_SIZE                 100
>>>> 
>>>> to:
>>>> 
>>>> #define INIT_TABLE_SIZE                 4096
>>>> 
>>>> then restarted postmaster with -B 1024 (this will prevent
>>>> out-of-free-buffers problem, I guess). Now everything seems to work
>>>> great!
>>>> 
>>>> I suspect that huge INIT_TABLE_SIZE prevented dynamic expanding the
>>>> hash tables and seems there's something wrong in the routines
>>>> responsible for that.
>> 
>> Seems like that -:(
>> 
>> If we'll not fix expand hash code before 6.5 release then
>> I would recommend to don't use INIT_TABLE_SIZE in
>> 
lockMethodTable-> lockHash = (HTAB *) ShmemInitHash(shmemName,
>> INIT_TABLE_SIZE, MAX_TABLE_SIZE,
>> &info, hash_flags);
>> 
>> and
>> 
lockMethodTable-> xidHash = (HTAB *) ShmemInitHash(shmemName,
>> INIT_TABLE_SIZE, MAX_TABLE_SIZE,
>> &info, hash_flags);
>> 
>> but use NLOCKENTS(maxBackends) instead.
>> 
>> Vadim