Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id 9A0881337B6C for ; Sat, 22 Jan 2011 22:08:35 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 67885-07 for ; Sun, 23 Jan 2011 02:08:29 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by mail.postgresql.org (Postfix) with ESMTP id 41EEA133616B for ; Sat, 22 Jan 2011 22:08:27 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id p0N28MYi000203; Sat, 22 Jan 2011 21:08:22 -0500 (EST) To: Robert Haas cc: Greg Smith , Fujii Masao , Magnus Hagander , pgsql-hackers@postgresql.org Subject: Re: auto-sizing wal_buffers In-reply-to: References: <20767.1294964709@sss.pgh.pa.us> <4D314406.3000703@2ndquadrant.com> <4D31D0E4.9000108@2ndquadrant.com> <11561.1295742146@sss.pgh.pa.us> <29279.1295746434@sss.pgh.pa.us> Comments: In-reply-to Robert Haas message dated "Sat, 22 Jan 2011 20:50:50 -0500" Date: Sat, 22 Jan 2011 21:08:22 -0500 Message-ID: <202.1295748502@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.91 tagged_above=-5 required=5 tests=BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201101/2197 X-Sequence-Number: 180034 Robert Haas writes: > This is certainly shorter than I wrote, which is good, but it strikes > me that the fundamental problem here is that the API for an assign > hook is fundamentally different for strings than it is for other data > types. I agree that that's annoying, but given that strings are pass-by-ref while the other GUC variable types are pass-by-value, it's not really very easy to make them alike. In any case, it's not too relevant to this patch, because an assign hook cannot solve this problem. As someone (I think you) pointed out upthread, an assign hook would only be useful if we were sure wal_buffers would in fact be assigned to by the config file, and that that would happen after shared_buffers acquired its final value. Since we can't assume either thing, the right way to approach it is to have an internal action that assigns a fresh value to wal_buffers after all the configuration processing is complete. Greg had the right design but didn't know how to change a GUC setting properly. There are a bunch of other hacks^Wfeatures that work similarly --- look around for SetConfigOption calls. regards, tom lane