Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 5B20464FCDA for ; Tue, 2 Sep 2008 06:43:20 -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 80469-03 for ; Tue, 2 Sep 2008 06:43:08 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail129162.authsmtp.net (outmail129162.authsmtp.net [62.13.129.162]) by postgresql.org (Postfix) with ESMTP id 80F1365010B for ; Tue, 2 Sep 2008 06:41:56 -0300 (ADT) Received: from mail-c187.authsmtp.com (mail-c187.authsmtp.com [62.13.128.33]) by punt3.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id m829fosj027655; Tue, 2 Sep 2008 10:41:50 +0100 (BST) Received: from [192.168.0.2] (85-211-229-97.dyn.gotadsl.co.uk [85.211.229.97]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id m829fmJu091824; Tue, 2 Sep 2008 10:41:48 +0100 (BST) Subject: Re: rmgr hooks and contrib/rmgr_hook From: Simon Riggs To: ITAGAKI Takahiro Cc: pgsql-hackers@postgresql.org 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> Content-Type: text/plain Date: Tue, 02 Sep 2008 10:49:40 +0100 Message-Id: <1220348980.4371.316.camel@ebony.2ndQuadrant> Mime-Version: 1.0 X-Mailer: Evolution 2.12.0 Content-Transfer-Encoding: 7bit X-Server-Quench: 5d6b2932-78d3-11dd-8155-001185d377ca X-AuthRoute: OCdxZQATClZOTQEd DAteCiNZVAwpPBRK HVkIKg5MJUcNSQVJ NksadBtFaAdbflxB HGQLW1xEUV17XWJ/ bwMfZQBDYEtPQQdo WVZARU1QEQdtHhxP WxYcW08vDUBGcX94 Z0IsXHBTWgp/IUAv QEdXF3ABbTNjdWEe BBRFfwJRdR5Kfh5E YlUrV3QKMjRJBC9q VxU2MCp5PTJYKz8d SwcBZVkVR1oRHzR7 XRUNBwIvGkoGL2Qg X-Authentic-SMTP: 61633235383639.squirrel.dmpriest.net.uk:1186/Kp X-Report-SPAM: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-Virus-Status: No virus detected - but ensure you scan with your own anti-virus system! 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/61 X-Sequence-Number: 123190 On Tue, 2008-09-02 at 18:30 +0900, ITAGAKI Takahiro wrote: > Simon Riggs 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. Exactly why I want to malloc it. > 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. Good point. If others agree, I will re-implement this way. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support