Re: rmgr hooks and contrib/rmgr_hook

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: rmgr hooks and contrib/rmgr_hook
Дата
Msg-id 48CB72C8.1070700@enterprisedb.com
обсуждение исходный текст
Ответ на Re: rmgr hooks and contrib/rmgr_hook  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: rmgr hooks and contrib/rmgr_hook
Список 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 по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: PLUGINS Functionlity in Win32 build scripts
Следующее
От: "Florian G. Pflug"
Дата:
Сообщение: Re: Transaction Snapshots and Hot Standby