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

From ITAGAKI Takahiro
Subject Re: rmgr hooks and contrib/rmgr_hook
Date
Msg-id 20080902174613.76B2.52131E4D@oss.ntt.co.jp
Whole thread Raw
Responses Re: rmgr hooks and contrib/rmgr_hook  (Simon Riggs <simon@2ndQuadrant.com>)
Re: rmgr hooks and contrib/rmgr_hook  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
Simon Riggs <simon@2ndQuadrant.com> wrote:

> > Why do we need to set rmgr_hook in _PG_init(), and add or mofify rmgrs
> > in our hook functions?
> 
> 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.

Um? AFAICS RmgrTable is not accessed in XLogInsert unless we use WAL_DEBUG.

I see that RmgrTable should be malloc'd when required,
but there is another issue; when to load rmgr libraries.

Rmgr objects are needed only in startup process during recovery.
If we want to reduce resource consumption by rmgrs, I think it is
better not to load rmgr libraries through shared_preload_libraries.
We don't have to load rmgr libs if recovery is not needed or after recovery.

How about adding a new variable "recovery_preload_libaries" like as
shared_preload_libraries? Rmgr libs in it are loaded only in startup
process and only if recovery is needed.

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




pgsql-hackers by date:

Previous
From: "Ryan Bradetich"
Date:
Subject: Re: statement_cost_limit for regression testing.
Next
From: "Pavel Stehule"
Date:
Subject: Re: statement_cost_limit for regression testing.