Re: rmgr hooks and contrib/rmgr_hook - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: rmgr hooks and contrib/rmgr_hook
Date
Msg-id 87k5ddmn2d.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: rmgr hooks and contrib/rmgr_hook  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: rmgr hooks and contrib/rmgr_hook  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
Simon Riggs <simon@2ndQuadrant.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


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Transaction Snapshots and Hot Standby
Next
From: Alvaro Herrera
Date:
Subject: Re: plpgsql is not translate-aware