"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Ouch. So this has been broken (by me, I think :-() since 8.0. Tells
>> you something about how many people use hash indexes :-(
> Yeah. Also, this is very hard to trigger without --enable-cassert (or
> just CLOBBER_FREED_MEMO
I wrote:
> Ouch. So this has been broken (by me, I think :-() since 8.0. Tells
> you something about how many people use hash indexes :-(
Actually it's not that bad --- this particular test case doesn't crash
in 8.0 or 8.1. I'm guessing we rearranged the order of transaction
abort processing in
Tom Lane wrote:
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
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 t
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> 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
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 te
