Re: rmgr hooks and contrib/rmgr_hook

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.

> * 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.

And as Tom points out startup isn't often enough. Would WAL headers even be
often enough? We would have to ensure there was never two versions of the
plugin in the same WAL file.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's On-Demand Production Tuning