Folks, do we have anything to revisit here?
> 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
>
>
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026