Re: [HACKERS] Open 6.5 items
От | Vadim Mikheev |
---|---|
Тема | Re: [HACKERS] Open 6.5 items |
Дата | |
Msg-id | 37525780.99FAC65B@krs.ru обсуждение исходный текст |
Ответ на | Re: [HACKERS] Open 6.5 items (Tatsuo Ishii <t-ishii@sra.co.jp>) |
Ответы |
Re: [HACKERS] Open 6.5 items
Re: [HACKERS] Open 6.5 items |
Список | 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 по дате отправления: