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

From Heikki Linnakangas
Subject Re: rmgr hooks and contrib/rmgr_hook
Date
Msg-id 48CB72C8.1070700@enterprisedb.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 wrote:
> On Tue, 2008-09-02 at 11:39 -0400, Tom Lane wrote:
>> , I'm not seeing the use-case
>> for an rmgr that only executes during recovery; in fact I'm not entirely
>> sure that I see a use-case for this entire patch.  Where are the WAL
>> records that the "loadable rmgr" processes going to come from?
> 
> There is ample reason to do this. I covered this in my first post,
> please re-read up thread. You have commented on this post already, so
> I'm suprised by your comments.

I think there's two different use cases here:

1. Filter WAL that's already generated, or is being generated by an 
unmodified PostgreSQL instance.

2. Allow external modules to define new resource managers.

The examples you posted with the patch were of type 1. That's a very 
valid use case, the example of only restoring a single database seems 
like a useful tool. Another tool like that is pglesslog, although that 
one couldn't actually be implemented with these hooks. I'm sure there's 
more tricks like that people would find useful, if the tools existed. 
The importance of the WAL will only increase as more people start to use 
it for PITR, replication etc.

The 2nd use case, however, I find pretty unconvincing. I can't think of 
a good example of that. Anything that needs to define its own resource 
manager is very low-level stuff, and probably needs to go into the core 
anyway.

So, let's focus on the 1st use case. I think a better approach for that 
is to implement the filters as external programs, like pglesslog. It 
allows more flexibility, although it also means that you can't rely on 
existing backend functions to manipulate the WAL. I'd love to see a "WAL 
toolkit" on pgfoundry, with tools like the filter to only restore a 
single database, pglesslog, a WAL record viewer etc. A while ago, you 
also talked about replacing the Slony triggers in the master with a tool 
that reads the WAL; another good example of an external tool that needs 
to read WAL. The toolkit could provide some sort of a framework and 
common user interface to read and write WAL files for all those tools.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: PLUGINS Functionlity in Win32 build scripts
Next
From: "Florian G. Pflug"
Date:
Subject: Re: Transaction Snapshots and Hot Standby