Skip site navigation (1) Skip section navigation (2)

Re: Error during hash index scans can cause postgres halt!

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 (view raw or flat)
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

In response to

Responses

pgsql-bugs by date

Next:From: Bruce MomjianDate: 2008-03-07 12:18:54
Subject: Re: [BUGS] BUG #3975: tsearch2 index should not bomb out of 1Mb limit
Previous:From: Jan StrubeDate: 2008-03-07 09:38:43
Subject: BUG #4019: Comparison of user defined domain doesn't work

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group