From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@commandprompt.com>
Cc: Gregory Stark <stark@enterprisedb.com>
Cc: ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: pgsql-hackers@postgresql.org
Subject: Re: CSStorm occurred again by postgreSQL8.2
Date: Thu, 14 Sep 2006 10:43:19 -0400
Message-ID: <29128.1158244999@sss.pgh.pa.us> (raw)
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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, alvherre@commandprompt.com, stark@enterprisedb.com, itagaki.takahiro@oss.ntt.co.jp, bruce@momjian.us
Subject: Re: CSStorm occurred again by postgreSQL8.2
In-Reply-To: <29128.1158244999@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox