Re: rmgr hooks and contrib/rmgr_hook
От | Simon Riggs |
---|---|
Тема | Re: rmgr hooks and contrib/rmgr_hook |
Дата | |
Msg-id | 1220345064.4371.275.camel@ebony.2ndQuadrant обсуждение исходный текст |
Ответ на | Re: rmgr hooks and contrib/rmgr_hook (ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>) |
Список | pgsql-patches |
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
В списке pgsql-patches по дате отправления: