Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 1564464FCE1 for ; Mon, 15 Sep 2008 14:04:17 -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 20553-06 for ; Mon, 15 Sep 2008 14:04:14 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail128088.authsmtp.com (outmail128088.authsmtp.com [62.13.128.88]) by postgresql.org (Postfix) with ESMTP id 1BF5464FCC6 for ; Mon, 15 Sep 2008 14:04:13 -0300 (ADT) Received: from mail-c187.authsmtp.com (mail-c187.authsmtp.com [62.13.128.33]) by punt5.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id m8FH3Ylh074034; Mon, 15 Sep 2008 18:03:34 +0100 (BST) Received: from [192.168.0.3] (85-211-98-178.dyn.gotadsl.co.uk [85.211.98.178]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id m8FH3WCC017081; Mon, 15 Sep 2008 18:03:32 +0100 (BST) Subject: Re: rmgr hooks and contrib/rmgr_hook From: Simon Riggs To: Gregory Stark Cc: Tom Lane , Heikki Linnakangas , ITAGAKI Takahiro , pgsql-hackers@postgresql.org In-Reply-To: <87k5ddmn2d.fsf@oxford.xeocode.com> 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> <87sks1oi4o.fsf@oxford.xeocode.com> <24006.1221483138@sss.pgh.pa.us> <1221485063.3913.1350.camel@ebony.2ndQuadrant> <25319.1221487473@sss.pgh.pa.us> <1221490804.3913.1406.camel@ebony.2ndQuadrant> <87k5ddmn2d.fsf@oxford.xeocode.com> Content-Type: text/plain Date: Mon, 15 Sep 2008 18:03:56 +0100 Message-Id: <1221498236.3913.1442.camel@ebony.2ndQuadrant> Mime-Version: 1.0 X-Mailer: Evolution 2.12.0 Content-Transfer-Encoding: 7bit X-Server-Quench: 3a415593-8348-11dd-8155-001185d377ca X-AuthRoute: OCdxZQATClZOTQEd DAteCiNZVAwpPBRK HVkIKg5MJUcNSQVJ NksacxtFaQBbflxB HGQLW1xEUVV7WWB/ aAgfZQBDYEtPQQxi TklOSk1QEQdtHhxP WxZoKhoVBHZGeXlw bUcsXXRcVAp5JEJ8 R0tdFnAOZmNodWEe BBRFfwJRdR5Kfh5E YlUrV3QKMjRJBC9q VxU2MCp5PTJYKz8d SwcBZVkVR1oRHzR7 XRUNBwIvGkoGL19p X-Authentic-SMTP: 61633235383639.squirrel.dmpriest.net.uk:1186/Kp X-Report-SPAM: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-Virus-Status: No virus detected - but ensure you scan with your own anti-virus system! 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/988 X-Sequence-Number: 124117 On Mon, 2008-09-15 at 16:43 +0100, Gregory Stark wrote: > Simon Riggs writes: > > > Bottom line is that any backup of Postgres needs to include plugin > > directories, otherwise parts of the application could stop working > > following restore. This patch doesn't change that. > > No, backups of executables are normally not the same backups as the data and > in many cases -- minor upgrades for example -- cannot be. So you advise your clients to do backup in two halves. Then complain that this is a bad way to do a backup because it may cause insurmountable problems on restore. And then seek to reject a patch because of that, even though similar problems already exist in other parts of the system. I'm sorry, but that is circular, then faulted logic. If you do a minor upgrade that changes the on-disk format of *any* part of the system then you have just introduced a limitation into what software can be used for restore. That could be a new version of a custom datatype just as easily as it could be an rmgr plugin. Shall we ban custom datatypes? Should we add a version number into every varlen header just in case somebody switched release levels, then forgot? > > * add the rmgr bms to the long header of each WAL file > > > > * change !RmgrIdIsValid() so that it causes FATAL by default. This then > > allows people to correct a mistake and retry. We provide an option to > > treat such errors as corrupt data and assume we have reached the end of > > WAL. > > I'm not sure but I think this just begs the question. The problem is to ensure > that the rmgrid means the same thing on the restoring database as it does on > the original database, or at least a compatible version. I think this would > mean having a long text description and version number to compare. Why is that any different to using functions or other plugins? If you restore data into a database where the functions have the same names, yet do different things then you are in trouble. Period. If you don't use an rmgr plugin at all then you have nothing different to do, nor will you see any different messages. If you use *any* external server software, expect to read the instructions or have problems. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support