Thread: rmgr hooks and contrib/rmgr_hook

As previously discussed on -hackers on Aug 19, "Proposed Resource
Manager Changes".

Enclosed are two closely related items:

1) A refactoring of calls to Rmgr code from xlog.c, and having isolated
the code for rmgrs then to allow rmgr plugins to modify and/or add rmgrs
to Postgres. Includes additional code to generate log messages so we can
see what is happening after plugin has executed.

Introduces a shared memory area for Rmgrs that allows each backend to
read which RmgrIds are valid for the currently running server, allowing
call to be made during XLogInsert() to validate rmgrid. (The validation
uses a fixed length BitMapSet, a minor new invention for this patch, but
that is begging to be refactored - I await advice and/or comments on the
fastest way to do this if that isn't it.)

(I'd like to rip out WAL_DEBUG completely in favour of this new
mechanism, but I haven't done that here).

2) contrib module that contains an example rmgr_hook - actually two
examples in one module

These have both been tested in normal mode, WAL_DEBUG mode and in warm
standby recovery, so not a WIP progress patch.

--
 Simon Riggs           www.2ndQuadrant.com
 PostgreSQL Training, Services and Support

Simon Riggs <simon@2ndQuadrant.com> wrote:

> 1) A refactoring of calls to Rmgr code from xlog.c, and having isolated
> the code for rmgrs then to allow rmgr plugins to modify and/or add rmgrs
> to Postgres. Includes additional code to generate log messages so we can
> see what is happening after plugin has executed.

Why do we need to set rmgr_hook in _PG_init(), and add or mofify rmgrs
in our hook functions? I think it is possible to modify RmgrTable
directly in _PG_init() instead of to have rmgr_hook. If we can do so,
the patch would be more simple, no? Am I missing something?


Index: src/backend/access/transam/rmgr.c
===================================================================
--- src/backend/access/transam/rmgr.c    (head)
+++ src/backend/access/transam/rmgr.c    (new)
@@ -25,1 +25,1 @@
-const RmgrData RmgrTable[RM_MAX_ID + 1] = {
+RmgrData RmgrTable[MAX_NUM_RMGRS + 1] = {

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center

On Mon, 2008-09-01 at 12:42 +0900, ITAGAKI Takahiro wrote:
> Simon Riggs <simon@2ndQuadrant.com> wrote:
>
> > 1) A refactoring of calls to Rmgr code from xlog.c, and having isolated
> > the code for rmgrs then to allow rmgr plugins to modify and/or add rmgrs
> > to Postgres. Includes additional code to generate log messages so we can
> > see what is happening after plugin has executed.
>
> Why do we need to set rmgr_hook in _PG_init(), and add or mofify rmgrs
> in our hook functions? I think it is possible to modify RmgrTable
> directly in _PG_init() instead of to have rmgr_hook. If we can do so,
> the patch would be more simple, no? Am I missing something?

If we modify RmgrTable in _PG_init() then we would have to have that
structure available in all backends, which was a stated objective to
avoid. We would still need a fast access data structure for the
XLogInsert() check, so the RmgrTable would just be wasted space in all
normal backends. In the patch, plugin is only called when we call
RmgrInitialize(), so the memory is malloc'd only when required.

The other reason is that this way of doing things is common to most
other server hooks. It allows the loaded module to specify that there
will be a plugin, but for the server to determine when that is called.
Calling code at the time _PG_init() runs limits us to certain types of
activity.

--
 Simon Riggs           www.2ndQuadrant.com
 PostgreSQL Training, Services and Support