X-Original-To: pgsql-hackers-postgresql.org@postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id D08429FA15C for ; Thu, 14 Sep 2006 10:58:07 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 31325-07 for ; Thu, 14 Sep 2006 10:57:55 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id B24139F944D for ; Thu, 14 Sep 2006 10:58:03 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.6/8.13.6) with ESMTP id k8EDvxRR028516; Thu, 14 Sep 2006 09:57:59 -0400 (EDT) To: Gregory Stark cc: Alvaro Herrera , ITAGAKI Takahiro , Bruce Momjian , pgsql-hackers@postgresql.org Subject: Re: CSStorm occurred again by postgreSQL8.2 In-reply-to: <28167.1158241250@sss.pgh.pa.us> 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> Comments: In-reply-to Tom Lane message dated "Thu, 14 Sep 2006 09:40:50 -0400" Date: Thu, 14 Sep 2006 09:57:59 -0400 Message-ID: <28515.1158242279@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.108 tagged_above=0 required=5 tests=AWL, SPF_HELO_PASS, SPF_PASS X-Spam-Level: X-Archive-Number: 200609/1101 X-Sequence-Number: 90630 I wrote: > I see a bug though, which is that RecordSubTransactionAbort() calls > GetCurrentTransactionId() before having verified that it needs to do > anything. This means that we'll generate and then discard an XID > uselessly in a failed subxact that didn't touch disk. Well, it would be a bug except that RecordSubTransactionAbort isn't called unless the current subxact has an XID. Perhaps a comment would be appropriate but there's nothing to fix here. 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. regards, tom lane