Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id A558664FD1F for ; Tue, 2 Sep 2008 07:38:32 -0300 (ADT) Received: from postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 38491-08 for ; Tue, 2 Sep 2008 07:38:23 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by postgresql.org (Postfix) with ESMTP id B6CDB64FCF5 for ; Tue, 2 Sep 2008 07:38:26 -0300 (ADT) Received: by ey-out-2122.google.com with SMTP id 6so887791eyi.61 for ; Tue, 02 Sep 2008 03:38:23 -0700 (PDT) Received: by 10.210.78.16 with SMTP id a16mr8073940ebb.125.1220351903732; Tue, 02 Sep 2008 03:38:23 -0700 (PDT) Received: from ?80.222.42.69? ( [80.222.42.69]) by mx.google.com with ESMTPS id d23sm39645187nfh.11.2008.09.02.03.38.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 02 Sep 2008 03:38:23 -0700 (PDT) Message-ID: <48BD179C.4090903@enterprisedb.com> Date: Tue, 02 Sep 2008 13:38:20 +0300 Organization: EnterpriseDB User-Agent: Mozilla-Thunderbird 2.0.0.14 (X11/20080509) MIME-Version: 1.0 To: ITAGAKI Takahiro CC: Simon Riggs , pgsql-hackers@postgresql.org Subject: Re: rmgr hooks and contrib/rmgr_hook References: <20080901121833.4A18.52131E4D@oss.ntt.co.jp> <1220345064.4371.275.camel@ebony.2ndQuadrant> <20080902174613.76B2.52131E4D@oss.ntt.co.jp> In-Reply-To: <20080902174613.76B2.52131E4D@oss.ntt.co.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit From: Heikki Linnakangas X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200809/65 X-Sequence-Number: 123194 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