Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id AFE1B64FCE1 for ; Mon, 15 Sep 2008 06:47:52 -0300 (ADT) Received: from postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 19983-07-2 for ; Mon, 15 Sep 2008 06:47:43 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by postgresql.org (Postfix) with ESMTP id AC4E564FD03 for ; Mon, 15 Sep 2008 06:47:41 -0300 (ADT) Received: by ey-out-2122.google.com with SMTP id 6so862408eyi.61 for ; Mon, 15 Sep 2008 02:47:39 -0700 (PDT) Received: by 10.210.115.17 with SMTP id n17mr9869421ebc.148.1221472059549; Mon, 15 Sep 2008 02:47:39 -0700 (PDT) Received: from oxford.xeocode.com.enterprisedb.com ( [82.16.16.210]) by mx.google.com with ESMTPS id q9sm5340970gve.5.2008.09.15.02.47.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 15 Sep 2008 02:47:38 -0700 (PDT) To: Simon Riggs Cc: Heikki Linnakangas , Tom Lane , ITAGAKI Takahiro , pgsql-hackers@postgresql.org Subject: Re: rmgr hooks and contrib/rmgr_hook In-Reply-To: <1221470800.3913.1229.camel@ebony.2ndQuadrant> (Simon Riggs's message of "Mon\, 15 Sep 2008 10\:26\:40 +0100") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) X-Draft-From: ("nnimap+imap.gmail.com:HACKERS" 1244) References: <20080901121833.4A18.52131E4D@oss.ntt.co.jp> <1220345064.4371.275.camel@ebony.2ndQuadrant> <20080902174613.76B2.52131E4D@oss.ntt.co.jp> <1220348980.4371.316.camel@ebony.2ndQuadrant> <14451.1220369969@sss.pgh.pa.us> <1220372673.4371.465.camel@ebony.2ndQuadrant> <48CB72C8.1070700@enterprisedb.com> <1221470800.3913.1229.camel@ebony.2ndQuadrant> From: Gregory Stark Organization: EnterpriseDB Date: Mon, 15 Sep 2008 10:47:35 +0100 Message-ID: <87sks1oi4o.fsf@oxford.xeocode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200809/950 X-Sequence-Number: 124079 Simon Riggs writes: > On Sat, 2008-09-13 at 10:59 +0300, Heikki Linnakangas wrote: > >> The 2nd use case, however, I find pretty unconvincing. I can't think of >> a good example of that. Anything that needs to define its own resource >> manager is very low-level stuff, and probably needs to go into the core >> anyway. > > New indexes are a big one, but I listed others also. > > Indexes have always been able to be added dynamically. Now they can be > recovered correctly as well. Hm, so currently if you want to add a new indexam you can't just insert into pg_am and make them recoverable. You basically have to build in your new index access method into Postgres with the new rmgr. That is annoying and a problem worth tackling. But I'm a bit worried about having this be an external plugin. There's no way to looking at a WAL file to know whether it will be recoverable with the plugins available. Worse, there's a risk you could have a plugin but not the *right* plugin. Perhaps this could be tackled simply by having startup insert a record listing all the rmgr's in use with identifying information and their version numbers. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support!