Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]
Amit Kapila <amit.kapila@huawei.com>
From: Amit Kapila <amit.kapila@huawei.com>
To: "'Amit Kapila'" <amit.kapila@huawei.com>, "'Alvaro Herrera'" <alvherre@2ndquadrant.com>
Cc: "'Greg Smith'" <greg@2ndQuadrant.com>, "'Robert Haas'" <robertmhaas@gmail.com>, "'Greg Stark'" <stark@mit.edu>, "'Andres Freund'" <andres@2ndquadrant.com>, "'Boszormenyi Zoltan'" <zb@cybertec.at>, <pgsql-hackers@postgresql.org>
Date: 2013-03-25T12:22:11Z
Lists: pgsql-hackers
Attachments
- set_persistent_v14.patch (application/octet-stream) patch v14
On Saturday, March 23, 2013 7:21 AM Amit Kapila wrote: > On Friday, March 22, 2013 7:33 PM Alvaro Herrera wrote: > > Amit Kapila escribió: > > > On Friday, March 22, 2013 8:57 AM Alvaro Herrera wrote: > > > > Amit Kapila escribió: > > > > > > > I think adding new syntax change is little scary for me, not > for > > > > > the matter of implementation but for building consensus on > > syntax. > > > > > > > > I cannot but agree on that point. > > > > > > Sorry, I don't get your point. > > > Do you mean to say that you don't agree with me and want new syntax > > as > > > proposed by you to be implemented? > > > > On the contrary, I was saying I agree with you on the difficulty on > > getting consensus on this. > > Now based on final discussion, I will go-ahead and document the > behavior > rather than using SIGHUP at end or giving NOTICE at end of command. > Let me know if anybody still feels otherwise. Updated the patch to remove SIGHUP at end of command and updated docs accordingly. > Apart from this during Greg's testing, he found a performance problem > with > running pg_reload_conf() along with my patch the reason for which > actually > turns out to be a memory > growth. I have attempted to fix it in the patch ctx_growth_fix_v1.patch > which is currently attached in CF queue along with my Patch. > http://www.postgresql.org/message- > id/004801ce216b$e37c3b30$aa74b190$@kapila@ > huawei.com > I think that should be done irrespective of SET Persistent Patch. With Regards, Amit Kapila.