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

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