Re: rmgr hooks and contrib/rmgr_hook

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: rmgr hooks and contrib/rmgr_hook
Date: 2008-09-15 17:03:56
Message-ID: 1221498236.3913.1442.camel@ebony.2ndQuadrant
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches


On Mon, 2008-09-15 at 16:43 +0100, Gregory Stark wrote:
> Simon Riggs <simon(at)2ndQuadrant(dot)com> 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Treat 2008-09-15 17:07:46 Re: Transaction Snapshots and Hot Standby
Previous Message Alvaro Herrera 2008-09-15 16:58:54 Re: plpgsql is not translate-aware

Browse pgsql-patches by date

  From Date Subject
Next Message Ryan Bradetich 2008-09-16 02:45:25 Re: [PgFoundry] Unsigned Data Types [1 of 2]
Previous Message Jaime Casanova 2008-09-15 15:48:26 Re: [PgFoundry] Unsigned Data Types [1 of 2]