Re: [HACKERS] Open 6.5 items

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: t-ishii(at)sra(dot)co(dot)jp
Cc: PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: [HACKERS] Open 6.5 items
Date: 1999-05-28 06:07:55
Message-ID: 5158.927871675@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message D'Arcy J.M. Cain 1999-05-28 07:21:37 Re: [HACKERS] Open 6.5 items
Previous Message Tatsuo Ishii 1999-05-28 05:20:22 Re: [HACKERS] Open 6.5 items