Skip site navigation (1) Skip section navigation (2)

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

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Amit Kapila <amit(dot)kapila(at)huawei(dot)com>
Cc: 'Dimitri Fontaine' <dimitri(at)2ndQuadrant(dot)fr>,'Tom Lane' <tgl(at)sss(dot)pgh(dot)pa(dot)us>,'Fujii Masao' <masao(dot)fujii(at)gmail(dot)com>, cedric(at)2ndquadrant(dot)com,pgsql-hackers(at)postgresql(dot)org, 'Robert Haas' <robertmhaas(at)gmail(dot)com>,'Greg Smith' <greg(at)2ndquadrant(dot)com>,'Josh Berkus' <josh(at)agliodbs(dot)com>,'Magnus Hagander' <magnus(at)hagander(dot)net>,'Christopher Browne' <cbbrowne(at)gmail(dot)com>
Subject: Re: Proposal for Allow postgresql.conf values to be changed via SQL
Date: 2012-11-19 15:05:56
Message-ID: 20121119150555.GB4196@alvh.no-ip.org (view raw or flat)
Thread:
Lists: pgsql-hackers
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).

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services


In response to

Responses

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2012-11-19 15:16:39
Subject: Re: pg_dump --split patch
Previous:From: Dimitri FontaineDate: 2012-11-19 14:58:10
Subject: Re: ALTER command reworks

Privacy Policy | About PostgreSQL
Copyright © 1996-2013 The PostgreSQL Global Development Group