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

From Josh Berkus
Subject Re: Proposal for Allow postgresql.conf values to be changed via SQL
Date
Msg-id 50A28DB4.3060306@agliodbs.com
Whole thread Raw
In response to Re: Proposal for Allow postgresql.conf values to be changed via SQL  (Amit kapila <amit.kapila@huawei.com>)
Responses Re: Proposal for Allow postgresql.conf values to be changed via SQL  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Proposal for Allow postgresql.conf values to be changed via SQL  (Amit Kapila <amit.kapila@huawei.com>)
List pgsql-hackers
On 11/12/12 7:59 PM, Amit kapila wrote:
> On Monday, November 12, 2012 12:07 PM Greg Smith wrote:
> On 11/9/12 11:59 PM, Amit kapila wrote:
> 
>>> Please let me know if there are any objections or problems in above method of implementation,
>>> else I can go ahead to prepare the patch for the coming CF.
> 
>> It may be the case that the locking scheme Robert described is the best
>> approach here.  It seems kind of heavy to me though.  I suspect that
>> some more thinking about it might come up with something better.

So, here's the problem I'm seeing with having a single .auto file:  when
we write settings to a file, are we writing a *single* setting or *all
of a user's current settings*?

I was imagining writing single, specific settings, which inevitably
leads to one-setting-per-file, e.g.:

SET PERSISTENT work_mem = 256MB;

What Amit seems to be talking about is more EXPORT SETTINGS, where you
dump all current settings in the session to a file.  This seems likely
to produce accidental changes when the user writes out settings they've
forgotten they changed.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Proof of concept: standalone backend with full FE/BE protocol
Next
From: Tom Lane
Date:
Subject: Re: Proposal for Allow postgresql.conf values to be changed via SQL