Received: from localhost (maia-4.hub.org [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id EDEE79F9CAA for ; Fri, 24 Aug 2007 17:07:11 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 79186-01 for ; Fri, 24 Aug 2007 17:07:02 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from oxford.xeocode.com (unknown [87.127.95.196]) by postgresql.org (Postfix) with ESMTP id 8C2CE9F9ADA for ; Fri, 24 Aug 2007 17:07:02 -0300 (ADT) Received: from localhost.enta.net ([127.0.0.1] helo=oxford.xeocode.com) by oxford.xeocode.com with esmtp (Exim 4.67) (envelope-from ) id 1IOfQk-00035R-0V; Fri, 24 Aug 2007 21:06:54 +0100 To: "Tom Lane" Cc: "Steven Flatt" , "Mark Kirkwood" , "Bill Moran" , "Vivek Khera" , "Pgsql performance" Subject: Re: When/if to Reindex In-Reply-To: <2774.1187976535@sss.pgh.pa.us> (Tom Lane's message of "Fri\, 24 Aug 2007 13\:28\:55 -0400") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) X-Draft-From: ("nnimap+mail01.enterprisedb.com:INBOX" 33595) References: <357fa7590707181008k65ab2f20l55bebb3c14f52770@mail.gmail.com> <11801.1186624308@sss.pgh.pa.us> <357fa7590708090651p71b9bc47n66739f8dbbb4ff57@mail.gmail.com> <357fa7590708220955h441cd75ap4c0f0342a1c30a14@mail.gmail.com> <873aybw2le.fsf@oxford.xeocode.com> <357fa7590708231525h2f48ce4dw3e48ecca5ccddf72@mail.gmail.com> <17370.1187927942@sss.pgh.pa.us> <46CE6883.10104@paradise.net.nz> <357fa7590708240722m204d678eid02b7ce3470eba1a@mail.gmail.com> <1759.1187972125@sss.pgh.pa.us> <357fa7590708240956k18e3ba7dv735cdaa99a667312@mail.gmail.com> <2774.1187976535@sss.pgh.pa.us> From: Gregory Stark Organization: EnterpriseDB Date: Fri, 24 Aug 2007 21:06:53 +0100 Message-ID: <876434zogy.fsf@oxford.xeocode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200708/293 X-Sequence-Number: 26423 "Tom Lane" writes: > "Steven Flatt" writes: >> So, can we simply trust what's in pg_class.relpages and ignore looking >> directly at the index? > > No, we can't. In the light of morning I remember more about the reason > for the aforesaid patch: it's actually unsafe to read the pg_class row > at all if you have not got lock on the index. We are reading with > SnapshotNow in order to be sure we see up-to-date info, and that means > that a concurrent update of the row (eg, for REINDEX to report the new > relfilenode) can have the following behavior: Should reindex be doing an in-place update? Don't we have to do in-place updates for other system catalogs which are read in snapshotnow for precisely the same reasons? Alternatively, why does the planner need access to the pg_class entry and not just the pg_index record? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com