Re: [HACKERS] Open 6.5 items
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Open 6.5 items |
Дата | |
Msg-id | 5158.927871675@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Open 6.5 items (Tatsuo Ishii <t-ishii@sra.co.jp>) |
Список | pgsql-hackers |
Tatsuo Ishii <t-ishii@sra.co.jp> writes: > LockAcquire: xid table corrupted > This comes from: > /* > * Find or create an xid entry with this tag > */ > result = (XIDLookupEnt *) hash_search(xidTable, (Pointer) &item, > HASH_ENTER, &found); > if (!result) > { > elog(NOTICE, "LockAcquire: xid table corrupted"); > return STATUS_ERROR; > } > As you can see the aquired master lock never released, and all > backends get stucked. (of course, corrupted xid table is a problem too Actually, corrupted xid table is *the* problem --- whatever happens after that is just collateral damage. (The elog should likely be elog(FATAL) not NOTICE...) If I recall the dynahash.c code correctly, a null return value indicates either damage to the structure of the table (ie someone stomped on memory that didn't belong to them) or running out of memory to add entries to the table. The latter should be impossible if we sized shared memory correctly. Perhaps the table size estimation code has been obsoleted by recent changes? regards, tom lane
В списке pgsql-hackers по дате отправления: