From: | Greg Stark <stark(at)mit(dot)edu> |
---|---|
To: | Greg Smith <greg(at)2ndquadrant(dot)com> |
Cc: | Amit Kapila <amit(dot)kapila(at)huawei(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Boszormenyi Zoltan <zb(at)cybertec(dot)at>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Proposal for Allow postgresql.conf values to be changed via SQL [review] |
Date: | 2013-03-12 15:36:44 |
Message-ID: | CAM-w4HPodXZ=i-C70kPh4ExC2oTKN_-U4uZnj=SiphZee43t3w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Mar 12, 2013 at 9:06 AM, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
> That's jumping right over a few rounds of simpler ways to do this, and just
> going right to the approach we know allows adding more such options later
> with minimal grammar impact.
As Craig intimated, the minimal grammar impact would be simply
BEGIN;
set persistent maintenance_work_mem='2GB';
set persistent work_mem='2GB';
COMMIT;
Sending the sighup at transaction end seems like a fairly safe thing
to do too. It's hard to imagine it failing and if it did the worst
case would be that other backends would still have the old values too.
To be honest I went through the gucs last night looking for a better
example than this and didn't really find any compelling examples. The
best I could come up with was adjusting several query costs in tandem.
Hardly the end of the world if it didn't work. The worst case would be
some security sensitive option alongside a second parameter for
limiting its scope, but I couldn't find any such examples in a quick
search. (And that's probably a good thing)
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Kohei KaiGai | 2013-03-12 15:53:29 | Re: [v9.3] OAT_POST_ALTER object access hooks |
Previous Message | Alvaro Herrera | 2013-03-12 15:31:00 | Re: Fix document typo |