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 по дате отправления:

Предыдущее
От: Tatsuo Ishii
Дата:
Сообщение: Re: [HACKERS] Open 6.5 items
Следующее
От: "D'Arcy" "J.M." Cain
Дата:
Сообщение: Re: [HACKERS] Open 6.5 items