From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
To: ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>
Cc: Simon Riggs <simon@2ndQuadrant.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: rmgr hooks and contrib/rmgr_hook
Date: Tue, 02 Sep 2008 13:38:20 +0300
Message-ID: <48BD179C.4090903@enterprisedb.com> (raw)
In-Reply-To: <20080902174613.76B2.52131E4D@oss.ntt.co.jp>
References: <20080901121833.4A18.52131E4D@oss.ntt.co.jp>
<1220345064.4371.275.camel@ebony.2ndQuadrant>
<20080902174613.76B2.52131E4D@oss.ntt.co.jp>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-patches@postgresql.org
Cc: heikki.linnakangas@enterprisedb.com, itagaki.takahiro@oss.ntt.co.jp, simon@2ndQuadrant.com, pgsql-hackers@postgresql.org
Subject: Re: rmgr hooks and contrib/rmgr_hook
In-Reply-To: <48BD179C.4090903@enterprisedb.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox