To: Alvaro Herrera <alvherre@commandprompt.com>
cc: Gregory Stark <stark@enterprisedb.com>,
	ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>,
	Bruce Momjian <bruce@momjian.us>, pgsql-hackers@postgresql.org
Subject: Re: CSStorm occurred again by postgreSQL8.2 
In-reply-to: <20060914142222.GA525@alvh.no-ip.org> 
References: <20060808110913.50FA.ITAGAKI.TAKAHIRO@oss.ntt.co.jp>
	<200608260346.k7Q3k2g06954@momjian.us>
	<20060828181312.5638.ITAGAKI.TAKAHIRO@oss.ntt.co.jp>
	<13251.1157299738@sss.pgh.pa.us> <22080.1158198335@sss.pgh.pa.us>
	<87mz92so6n.fsf@enterprisedb.com> <27509.1158237711@sss.pgh.pa.us>
	<28167.1158241250@sss.pgh.pa.us> <28515.1158242279@sss.pgh.pa.us>
	<20060914142222.GA525@alvh.no-ip.org>
Comments: In-reply-to Alvaro Herrera <alvherre@commandprompt.com>
	message dated "Thu, 14 Sep 2006 10:22:22 -0400"
Date: Thu, 14 Sep 2006 10:43:19 -0400
Message-ID: <29128.1158244999@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Alvaro Herrera <alvherre@commandprompt.com> writes:
> Tom Lane wrote:
>> I think Theo's problem is probably somewhere else, too --- apparently
>> it's not so much that TransactionIdIsCurrentTransactionId takes a long
>> time as that something is calling it lots of times with no check for
>> interrupt.

> Could it be something like heap_lock_tuple?  It calls MultiXactIdWait,
> which calls GetMultXactIdMembers and TransactionIdIsCurrentTransactionId
> on each member.  (heap_update and heap_delete do the same thing).  I
> must admit I didn't read Theo's description on his scenario though.

He shows HeapTupleSatisfiesSnapshot as the next thing down the call
stack, so those scenarios don't seem quite right.  I'm wondering about a
CHECK_FOR_INTERRUPTS-free loop in either plperl or trigger handling,
myself.

Anyway, I was thinking some more about Theo's original suggestion that
the linked-list representation of childXids was too inefficient.  I'm
disinclined to use a hash as he suggests, but it strikes me that we
could very easily change the list into a dynamically extended array
--- and because the entries are surely added in increasing XID order,
such an array could be binary-searched.  This wouldn't be a win for
very small numbers of child XIDs, but for large numbers it would.

OTOH, there are probably enough other inefficiencies in handling large
numbers of subxact XIDs that speeding up TransactionIdIsCurrentTransactionId
might be a useless exercise.  It would be good to profile a test case
before spending much effort here.

			regards, tom lane