Horton
Menu

Re: Proposal for Allow postgresql.conf values to be changed via SQL

Amit Kapila <amit.kapila@huawei.com>

View thread
From: Amit Kapila <amit.kapila@huawei.com>
To: "'Alvaro Herrera'" <alvherre@2ndquadrant.com>
Cc: "'Dimitri Fontaine'" <dimitri@2ndQuadrant.fr>, "'Tom Lane'" <tgl@sss.pgh.pa.us>, "'Fujii Masao'" <masao.fujii@gmail.com>, <cedric@2ndquadrant.com>, <pgsql-hackers@postgresql.org>, "'Robert Haas'" <robertmhaas@gmail.com>, "'Greg Smith'" <greg@2ndquadrant.com>, "'Josh Berkus'" <josh@agliodbs.com>, "'Magnus Hagander'" <magnus@hagander.net>, "'Christopher Browne'" <cbbrowne@gmail.com>
Date: 2012-11-20T13:51:28Z
Lists: pgsql-hackers 
On Monday, November 19, 2012 9:07 PM Amit Kapila wrote:
> On Monday, November 19, 2012 8:36 PM Alvaro Herrera wrote:
> > Amit Kapila escribió:
> >
> > > The only point I can see against SET PERSISTENT is that other
> variants
> > of
> > > SET command can be used in
> > > transaction blocks means for them ROLLBACK TO SAVEPOINT
> functionality
> > works,
> > > but for SET PERSISTENT,
> > > it can't be done.
> > > So to handle that might be we need to mention this point in User
> > Manual, so
> > > that users can be aware of this usage.
> > > If that is okay, then I think SET PERSISTENT is good to go.
> >
> > I think that's okay.  There are other commands which have some forms
> > that can run inside a transaction block and others not.  CLUSTER is
> > one example (maybe the only one?  Not sure).
> 
> In that case, it can have one more advantage that all configuration
> setting
> can be done with one command
> and in future we might want to have option like BOTH where the command
> will
> take effect for memory as well
> as file.
> 
> Can you think of any strong reason why not to have with Alter System
> Command?
> 
> In any case SET PERSISTENT is fine.

If no objections to SET PERSISTENT .. syntax, I shall update the patch for
implementation of same.

With Regards,
Amit Kapila.