From: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> |
---|---|
To: | "ykhuang" <hyk(at)ruc(dot)edu(dot)cn> |
Cc: | <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: Error during hash index scans can cause postgres halt! |
Date: | 2008-03-07 10:09:12 |
Message-ID: | 47D11448.4000805@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
ykhuang wrote:
> recurred through deadlock.
>
> client1:
> create table test(a int);
> create index id on test using hash(a);
> insert into test values(1);
> insert into test values(2);
> set enable_seqscan=off;
> begin;
> update test set a=a+1 where a=1;
>
> client2:
> set enable_seqscan=off;
> begin;
> update test set a=a+1 where a=2;
>
> client1:
> update test set a=a+1 where a=2;
>
> client2:
> update test set a=a+1 where a=1;
I can reproduce this, with --enable-cassert. It crashes when aborting
the transaction, in ReleaseResources_hash. The HashScanList items are
allocated in ExecutorState memory context, but that context has already
been deleted by the time we get to ReleaseResources_hash.
Not sure how to fix this. There's this piece of code in AtAbort_Portals:
> /*
> * Any resources belonging to the portal will be released in the
> * upcoming transaction-wide cleanup; they will be gone before we run
> * PortalDrop.
> */
> portal->resowner = NULL;
>
> /*
> * Although we can't delete the portal data structure proper, we can
> * release any memory in subsidiary contexts, such as executor state.
> * The cleanup hook was the last thing that might have needed data
> * there.
> */
> MemoryContextDeleteChildren(PortalGetHeapMemory(portal));
MemoryContextDeleteChildren is where we free the HashScanList item we
later try to access. It seems like a simple fix would be to call
ResourceOwnerRelease before that, instead of relying on the
transaction-wide cleanup.
Another idea would be to allocate the HashScanList items in a
longer-lived memory context. The IndexScanDesc struct pointed to by the
HashScanList would still be in ExecutorState context, but that's all
right because we don't need to access it in ReleaseResources_hash.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2008-03-07 12:18:54 | Re: [BUGS] BUG #3975: tsearch2 index should not bomb out of 1Mb limit |
Previous Message | Jan Strube | 2008-03-07 09:38:43 | BUG #4019: Comparison of user defined domain doesn't work |