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
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 |