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

From Tom Lane
Subject Re: [HACKERS] Open 6.5 items
Date
Msg-id 5158.927871675@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Open 6.5 items  (Tatsuo Ishii <t-ishii@sra.co.jp>)
List 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 by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: [HACKERS] Open 6.5 items
Next
From: "D'Arcy" "J.M." Cain
Date:
Subject: Re: [HACKERS] Open 6.5 items