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 E4E589FA0C4 for ; Thu, 14 Sep 2006 10:41:05 -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 26384-09 for ; Thu, 14 Sep 2006 10:40:46 -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 E9BE39FA15C for ; Thu, 14 Sep 2006 10:40:54 -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 k8EDeowf028168; Thu, 14 Sep 2006 09:40:50 -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: <27509.1158237711@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> Comments: In-reply-to Tom Lane message dated "Thu, 14 Sep 2006 08:41:51 -0400" Date: Thu, 14 Sep 2006 09:40:50 -0400 Message-ID: <28167.1158241250@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.107 tagged_above=0 required=5 tests=AWL, SPF_HELO_PASS, SPF_PASS X-Spam-Level: X-Archive-Number: 200609/1099 X-Sequence-Number: 90628 I wrote: > Yeah, I was just looking at that. Removing useless entries from the > child-xid list would presumably help him. Considering we're not even > formally in beta yet, I'm probably being too conservative to recommend > we not touch it. Actually ... wait a minute. We do not assign an XID to a subtransaction at all unless it writes a tuple to disk (see GetCurrentTransactionId and its callers). So this whole "optimization" idea is redundant. 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. Worth fixing, but it doesn't look like this is Theo's problem. Unless I'm missing something, Theo's problem must involve having done tuple updates in 4.6M different subtransactions. regards, tom lane