Re: Proposal for Allow postgresql.conf values to be changed via SQL [review] - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]
Date
Msg-id CAM-w4HPodXZ=i-C70kPh4ExC2oTKN_-U4uZnj=SiphZee43t3w@mail.gmail.com
Whole thread Raw
In response to Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]  (Greg Smith <greg@2ndQuadrant.com>)
Responses Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Tue, Mar 12, 2013 at 9:06 AM, Greg Smith <greg@2ndquadrant.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



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Fix document typo
Next
From: Kohei KaiGai
Date:
Subject: Re: [v9.3] OAT_POST_ALTER object access hooks