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 48BD179C.4090903@enterprisedb.com
Whole thread Raw
In response to Re: rmgr hooks and contrib/rmgr_hook  (ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>)
Responses Re: rmgr hooks and contrib/rmgr_hook  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
ITAGAKI Takahiro wrote:
> 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.

It doesn't seem worth it to introduce a new GUC like that, just to 
reduce the memory usage a tiny bit in the rare case that a rmgr plugin 
is present. How much memory will loading an extra library consume 
anyway? Depends on the library of course, but I believe we're talking 
about something in the ballpark of a few hundred kb. Besides, a decent 
OS should swap that to disk, if it's not used, and the system is tight 
on memory.

Also, presumably the library containing the recovery functions, also 
contains the functions that generate those WAL records. So, it will be 
needed after startup anyway, if the plugin is used at all.

There's one more reason to use shared_preload_libraries. It provides a 
sanity check that the library required for recovery is present and can 
be loaded, even when no recovery is required. If you have misconfigured 
your system so that it can't recover, you want to find out sooner rather 
than later when recovery is needed.

So IMHO, just use shared_preload_libraries.

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


pgsql-hackers by date:

Previous
From: "Marko Kreen"
Date:
Subject: Re: [PATCH] Make gram.y use palloc/pfree for memory management
Next
From: "Marko Kreen"
Date:
Subject: Re: Auto-explain patch