Re: rmgr hooks (v2) - Mailing list pgsql-hackers

On Wed, Jan 21, 2009 at 1:25 PM, Simon Riggs <simon@2ndquadrant.com> wrote:

> The only reasonable way to examine the contents of WAL files is with
> reference to a copy of the catalog that wrote them, timed *exactly* in
> synchronisation with the WAL stream.

This is a good point.


>> Regarding the example plugin included, for debugging purposes you could
>> just compile with WAL_DEBUG, and the plugin to suppress actions for all
>> but one database is clearly not ready for any real work. It only
>> suppresses heapam records, replaying index updates and full-page-images
>> as usual, and it requires that you know the Oid of the database,
>
> They're minor examples, so don't reject the plugin patch because the
> example of usage isn't as useful as it could be. I'm hardly likely to
> invest lots of time in a plugin while the approach has not been agreed,
> am I?

Well for these two cases I think the question is would the be better
done from within the core instead of a plugin? And if they are better
done as a plugin are the advantages strong enough to outweigh the
downsides of a plugin. (This actually reinforces the point that doing
these things externally is not very realistic.)

I don't see much of an advantage for plugins instead of core features
for either of these two cases. And given how tightly bound to a
specific version and the WAL record formats of that version a plugin
will have are there any advantages? If a plugin will only work with a
particular version of Postgres and it needs access to internal include
files then what separation does it give? From a code structure point
of view it may as well be integrated, in which case anyone who
modifies the wal structures is more likely to keep the other features
up to date.

Moreover, for things like restoring a single database I think there
are further disadvantages. You would have to ensure that the records
you're skipping don't result in an incoherent database. That means
either doing a cold restore of just a single database. That could be
really cool, you could, for instance allow rolling back a single
database to a hot backup + PITR without even shutting down the rest of
the cluster. However for anything like this to work properly you have
to know what version of the data files were restored and what version
the rest of the database is at, etc. If it's a plugin I think you
don't have enough information or control of the overall state to
handle it.

The only advantage that remains, I think, is the real-world concern
that you can have proprietary plugins that add features to the
database for dealing with emergency situations. It also means people
can experiment with features without maintaining a fork. That's not a
trivial advantage at all. I could see that being quite useful. But on
balance, considering how critical backups and restores are I would
personally avoid experimenting in this area anyways.

-- 
greg