Re: [HACKERS] Open 6.5 items - Mailing list pgsql-hackers

From Vadim Mikheev
Subject Re: [HACKERS] Open 6.5 items
Date
Msg-id 37525780.99FAC65B@krs.ru
Whole thread Raw
In response to Re: [HACKERS] Open 6.5 items  (Tatsuo Ishii <t-ishii@sra.co.jp>)
Responses Re: [HACKERS] Open 6.5 items  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [HACKERS] Open 6.5 items  (Bruce Momjian <maillist@candle.pha.pa.us>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: [HACKERS] Open 6.5 items
Next
From: The Hermit Hacker
Date:
Subject: Re: [HACKERS] History of PostgreSQL