Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id CE24E1337B7E for ; Mon, 14 Feb 2011 06:40:49 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 54163-07 for ; Mon, 14 Feb 2011 10:40:42 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by mail.postgresql.org (Postfix) with ESMTP id E3AED1337B51 for ; Mon, 14 Feb 2011 06:40:41 -0400 (AST) Received: from source ([209.85.161.53]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKTVkGqRHiD+9Y1eHiWdC0hF3YOKDzYEcE@postini.com; Mon, 14 Feb 2011 02:40:42 PST Received: by fxm11 with SMTP id 11so4863789fxm.12 for ; Mon, 14 Feb 2011 02:40:39 -0800 (PST) Received: by 10.223.87.5 with SMTP id u5mr4344728fal.48.1297680039882; Mon, 14 Feb 2011 02:40:39 -0800 (PST) Received: from [192.168.1.183] (dsl-hkibrasgw2-ff7ac300-240.dhcp.inet.fi [88.195.122.240]) by mx.google.com with ESMTPS id n15sm968004fam.12.2011.02.14.02.40.38 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 Feb 2011 02:40:38 -0800 (PST) Message-ID: <4D5906A5.8040602@enterprisedb.com> Date: Mon, 14 Feb 2011 12:40:37 +0200 From: Heikki Linnakangas User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; fi-FI; rv:1.9.1.16) Gecko/20101226 Icedove/3.0.11 MIME-Version: 1.0 To: Kevin.Grittner@wicourts.gov CC: YAMAMOTO Takashi , pgsql-hackers@postgresql.org Subject: Re: SSI bug? References: <4D566A08020000250003A90B@gw.wicourts.gov> <20110214050924.2E5E119CE7A@mail.netbsd.org> In-Reply-To: <20110214050924.2E5E119CE7A@mail.netbsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-4.2 tagged_above=-5 required=5 tests=BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3 X-Spam-Level: X-Archive-Number: 201102/1239 X-Sequence-Number: 182028 Looking at the prior/next version chaining, aside from the looping issue, isn't it broken by lock promotion too? There's a check in RemoveTargetIfNoLongerUsed() so that we don't release a lock target if its priorVersionOfRow is set, but what if the tuple lock is promoted to a page level lock first, and PredicateLockTupleRowVersionLink() is called only after that? Or can that not happen because of something else that I'm missing? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com