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 037C29FB22F for ; Mon, 7 Aug 2006 17:10:38 -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 57193-07 for ; Mon, 7 Aug 2006 17:10:34 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from lists.commandprompt.com (host-130.commandprompt.net [207.173.203.130]) by postgresql.org (Postfix) with ESMTP id 903E99FB273 for ; Mon, 7 Aug 2006 17:10:34 -0300 (ADT) Received: from alvh.no-ip.org (201-221-202-139.bk11-dsl.surnet.cl [201.221.202.139]) (authenticated bits=0) by lists.commandprompt.com (8.13.7/8.13.6) with ESMTP id k77KAY4o021725; Mon, 7 Aug 2006 13:10:35 -0700 Received: by alvh.no-ip.org (Postfix, from userid 1000) id E3B94C45036; Mon, 7 Aug 2006 16:10:14 -0400 (CLT) Date: Mon, 7 Aug 2006 16:10:14 -0400 From: Alvaro Herrera To: Tom Lane Cc: ITAGAKI Takahiro , pgsql-hackers@postgresql.org, Katsuhiko Okano Subject: Re: CSStorm occurred again by postgreSQL8.2 Message-ID: <20060807201014.GB32736@alvh.no-ip.org> Mail-Followup-To: Tom Lane , ITAGAKI Takahiro , pgsql-hackers@postgresql.org, Katsuhiko Okano References: <200607181650.EDC81237.LOBJUTPuIPPBLLV@oss.ntt.co.jp> <5126.1153241513@sss.pgh.pa.us> <20060807114525.5266.ITAGAKI.TAKAHIRO@oss.ntt.co.jp> <19738.1154956177@sss.pgh.pa.us> <20060807185243.GB26021@alvh.no-ip.org> <13175.1154979751@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <13175.1154979751@sss.pgh.pa.us> User-Agent: Mutt/1.5.12-2006-07-14 X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on projects.commandprompt.com X-Virus-Status: Clean X-Greylist: Sender succeded SMTP AUTH authentication, not delayed by milter-greylist-1.6 (lists.commandprompt.com [192.168.2.159]); Mon, 07 Aug 2006 13:10:35 -0700 (PDT) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.857 tagged_above=0 required=5 tests=AWL, FORGED_RCVD_HELO, RCVD_IN_NJABL_PROXY X-Spam-Level: X-Archive-Number: 200608/448 X-Sequence-Number: 87941 Tom Lane wrote: > Alvaro Herrera writes: > > Tom Lane wrote: > >> I'm wondering about doing something similar to what > >> TransactionIdIsInProgress does, ie, make use of the PGPROC lists > >> of live subtransactions. > > > Well, that sounds awfully more expensive than setting > > local-to-my-database Xmins as well as global (all databases) Xmins :-) > > Only when you've got a lot of subtransactions. The point of this > discussion is to optimize for the few-or-none case. In any case, > the problem with the local/global bit was that you'd be expending > foreground-process cycles without any foreground-process return. > Being able to use a snapshot without consulting pg_subtrans will > certainly buy back some cycles... I can buy that. Some idle thoughts: I was thinking at what time was the most appropiate to insert or remove an Xid from the cache. We can do without any excl-locking because 1) we already assume the storing of an Xid to be atomic, and 2) no one can be interested in querying for an Xid before the originating transaction has had the chance to write a tuple with that Xid anyway. OTOH I think we only need to store live Xids and those finished that wrote a WAL record; we can drop subaborted and subcommitted if they didn't. On the third hand, are we going to sh-acquire the ProcArray lock while a GetSnapshotData copies all subxact Xids of all running transactions? ProcArrayLock will become more of a contention point than it already is. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support