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

2012-11-24 Thread Amit kapila
On Saturday, November 24, 2012 10:56 PM Tom Lane wrote: Amit kapila amit.kap...@huawei.com writes: On Friday, November 23, 2012 10:10 PM Fujii Masao wrote: What happens if the server crashes while SET PERSISTENT is writing the setting to the file? A partial write occurs and restart of the

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

2012-11-23 Thread Amit Kapila
On Thursday, November 22, 2012 10:09 PM Fujii Masao wrote: On Thu, Nov 22, 2012 at 9:38 PM, Amit kapila amit.kap...@huawei.com wrote: Patch to implement SET PERSISTENT command is attached with this mail. Now it can be reviewed. I got the following compile warnings: xact.c:1847: warning:

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

2012-11-23 Thread Fujii Masao
On Fri, Nov 23, 2012 at 6:56 PM, Amit Kapila amit.kap...@huawei.com wrote: When I remove postgresql.auto.conf, SET PERSISTENT failed. =# SET PERSISTENT synchronous_commit = 'local'; ERROR: failed to open postgresql.auto.conf file There can be 2 ways to handle this, either we recreate the

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

2012-11-23 Thread Amit kapila
On Friday, November 23, 2012 10:10 PM Fujii Masao wrote: On Fri, Nov 23, 2012 at 6:56 PM, Amit Kapila amit.kap...@huawei.com wrote: When I remove postgresql.auto.conf, SET PERSISTENT failed. =# SET PERSISTENT synchronous_commit = 'local'; ERROR: failed to open postgresql.auto.conf file

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

2012-11-22 Thread Amit kapila
On Tuesday, November 20, 2012 7:21 PM Amit Kapila wrote: 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

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

2012-11-22 Thread Fujii Masao
On Thu, Nov 22, 2012 at 9:38 PM, Amit kapila amit.kap...@huawei.com wrote: Patch to implement SET PERSISTENT command is attached with this mail. Now it can be reviewed. I got the following compile warnings: xact.c:1847: warning: implicit declaration of function 'AtEOXact_UpdateAutoConfFiles'

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

2012-11-20 Thread Amit Kapila
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

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

2012-11-19 Thread Dimitri Fontaine
Amit Kapila amit.kap...@huawei.com writes: We have discussion about below 3 different syntaxes for this command 1. ALTER SYSTEM 2. SET PERSISENT 3. pg_change_conf() I think to conclude, we need to evaluate which syntax has more advantages. Comparison for above syntax I think ALTER

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

2012-11-19 Thread Amit Kapila
On Monday, November 19, 2012 7:53 PM Dimitri Fontaine wrote: Amit Kapila amit.kap...@huawei.com writes: We have discussion about below 3 different syntaxes for this command 1. ALTER SYSTEM 2. SET PERSISENT 3. pg_change_conf() I think to conclude, we need to evaluate which syntax has

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

2012-11-19 Thread Alvaro Herrera
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

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

2012-11-19 Thread Amit Kapila
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,

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

2012-11-18 Thread Cédric Villemain
Le samedi 17 novembre 2012 22:57:49, Tom Lane a écrit : Fujii Masao masao.fu...@gmail.com writes: Do we really need to store the settings in a system table? Since WAL would be generated when storing the settings in a system table, this approach seems to prevent us from changing the

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

2012-11-18 Thread Amit Kapila
On Sunday, November 18, 2012 3:08 AM Fujii Masao wrote: On Sat, Nov 17, 2012 at 10:25 PM, Amit Kapila amit.kap...@huawei.com wrote: 1. have a system table pg_global_system_settings(key,value) Do we really need to store the settings in a system table? Since WAL would be generated when

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

2012-11-18 Thread Amit Kapila
On Sunday, November 18, 2012 3:28 AM Tom Lane wrote: Fujii Masao masao.fu...@gmail.com writes: Do we really need to store the settings in a system table? Since WAL would be generated when storing the settings in a system table, this approach seems to prevent us from changing the settings

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

2012-11-18 Thread Amit Kapila
On Sunday, November 18, 2012 3:22 PM Cédric Villemain wrote: Le samedi 17 novembre 2012 22:57:49, Tom Lane a écrit : Fujii Masao masao.fu...@gmail.com writes: Do we really need to store the settings in a system table? Since WAL would be generated when storing the settings in a system

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

2012-11-17 Thread Amit Kapila
On Friday, November 16, 2012 7:52 PM Cédric Villemain wrote: Le vendredi 16 novembre 2012 15:08:30, Amit Kapila a écrit : On Thursday, November 15, 2012 8:18 PM Amit kapila wrote: On Wednesday, November 14, 2012 12:24 AM Robert Haas wrote: On Mon, Nov 12, 2012 at 10:59 PM, Amit kapila

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

2012-11-17 Thread Fujii Masao
On Sat, Nov 17, 2012 at 10:25 PM, Amit Kapila amit.kap...@huawei.com wrote: 1. have a system table pg_global_system_settings(key,value) Do we really need to store the settings in a system table? Since WAL would be generated when storing the settings in a system table, this approach seems to

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

2012-11-17 Thread Tom Lane
Fujii Masao masao.fu...@gmail.com writes: Do we really need to store the settings in a system table? Since WAL would be generated when storing the settings in a system table, this approach seems to prevent us from changing the settings in the standby. That's a really good point: if we try to

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

2012-11-16 Thread Cédric Villemain
Le vendredi 16 novembre 2012 07:16:09, Amit Kapila a écrit : On Thursday, November 15, 2012 11:28 PM Cédric Villemain wrote: Le jeudi 15 novembre 2012 15:48:14, Amit kapila a écrit : On Wednesday, November 14, 2012 12:24 AM Robert Haas wrote: On Mon, Nov 12, 2012 at 10:59 PM, Amit

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

2012-11-16 Thread Amit Kapila
postgresql.conf values to be changed via SQL On Friday, November 16, 2012 1:55 PM Cédric Villemain wrote: Le vendredi 16 novembre 2012 07:16:09, Amit Kapila a écrit : On Thursday, November 15, 2012 11:28 PM Cédric Villemain wrote: Le jeudi 15 novembre 2012 15:48:14, Amit kapila a écrit

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

2012-11-16 Thread Amit Kapila
On Thursday, November 15, 2012 8:18 PM Amit kapila wrote: On Wednesday, November 14, 2012 12:24 AM Robert Haas wrote: On Mon, Nov 12, 2012 at 10:59 PM, Amit kapila amit.kap...@huawei.com wrote: Uh, no, I don't think that's a good idea. IMHO, what we should do is: 1. Read

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

2012-11-16 Thread Cédric Villemain
Le vendredi 16 novembre 2012 15:08:30, Amit Kapila a écrit : On Thursday, November 15, 2012 8:18 PM Amit kapila wrote: On Wednesday, November 14, 2012 12:24 AM Robert Haas wrote: On Mon, Nov 12, 2012 at 10:59 PM, Amit kapila amit.kap...@huawei.com wrote: Uh, no, I don't think that's a

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

2012-11-15 Thread Amit kapila
On Wednesday, November 14, 2012 12:24 AM Robert Haas wrote: On Mon, Nov 12, 2012 at 10:59 PM, Amit kapila amit.kap...@huawei.com wrote: Uh, no, I don't think that's a good idea. IMHO, what we should do is: 1. Read postgresql.conf.auto and remember all the settings we saw. If we see

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

2012-11-15 Thread Cédric Villemain
Le jeudi 15 novembre 2012 15:48:14, Amit kapila a écrit : On Wednesday, November 14, 2012 12:24 AM Robert Haas wrote: On Mon, Nov 12, 2012 at 10:59 PM, Amit kapila amit.kap...@huawei.com wrote: Uh, no, I don't think that's a good idea. IMHO, what we should do is: 1. Read

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

2012-11-15 Thread Amit Kapila
On Thursday, November 15, 2012 11:28 PM Cédric Villemain wrote: Le jeudi 15 novembre 2012 15:48:14, Amit kapila a écrit : On Wednesday, November 14, 2012 12:24 AM Robert Haas wrote: On Mon, Nov 12, 2012 at 10:59 PM, Amit kapila amit.kap...@huawei.com wrote: Uh, no, I don't think that's

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

2012-11-14 Thread Amit kapila
On Tuesday, November 13, 2012 9:29 AM Amit kapila wrote: On Monday, November 12, 2012 12:07 PM Greg Smith wrote: On 11/9/12 11:59 PM, Amit kapila wrote: 1) Change to add scanning a .conf directory in the default configuration using include-dir. This is a quick fix. I predict most of the

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

2012-11-13 Thread Josh Berkus
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.

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

2012-11-13 Thread Tom Lane
Josh Berkus j...@agliodbs.com writes: 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

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

2012-11-13 Thread Robert Haas
On Tue, Nov 13, 2012 at 1:16 PM, Tom Lane t...@sss.pgh.pa.us wrote: Josh Berkus j...@agliodbs.com writes: 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

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

2012-11-13 Thread Robert Haas
On Mon, Nov 12, 2012 at 10:59 PM, Amit kapila amit.kap...@huawei.com wrote: Is the above opinion about only locking or even on a way to write the changed things in a file as mentioned in point-1 in mail chain upthread. (Point-1: 1. While writing .auto file, it will always assume that .auto

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

2012-11-13 Thread Amit Kapila
On Wednesday, November 14, 2012 12:25 AM Robert Haas wrote: On Mon, Nov 12, 2012 at 10:59 PM, Amit kapila amit.kap...@huawei.com wrote: Is the above opinion about only locking or even on a way to write the changed things in a file as mentioned in point-1 in mail chain upthread. (Point-1:

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

2012-11-13 Thread Amit Kapila
On Tuesday, November 13, 2012 11:43 PM Josh Berkus wrote: 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,

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

2012-11-12 Thread Tom Lane
Greg Smith g...@2ndquadrant.com writes: Regardless, exactly how to prevent two concurrent processes from writing the same file feels like the last step in the small roadmap for what this feature needs. Write a temp file and use rename(2) to move it into place is the standard solution for

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

2012-11-12 Thread Amit kapila
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

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

2012-11-11 Thread Greg Smith
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

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

2012-11-09 Thread Amit kapila
On Thursday, November 08, 2012 7:56 PM Amit Kapila On Thursday, November 08, 2012 1:45 AM Robert Haas wrote: On Wed, Nov 7, 2012 at 2:50 PM, Josh Berkus j...@agliodbs.com wrote: Well, Magnus' proposed implementation supposed that the existing values *have* been loaded into the current

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

2012-11-08 Thread Amit Kapila
On Thursday, November 08, 2012 1:45 AM Robert Haas wrote: On Wed, Nov 7, 2012 at 2:50 PM, Josh Berkus j...@agliodbs.com wrote: Well, Magnus' proposed implementation supposed that the existing values *have* been loaded into the current session. I agree that with some locking and yet more

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

2012-11-08 Thread Alvaro Herrera
Amit Kapila escribió: 3. Two backends trying to write to .auto file we can use .auto.lock as the the lock by trying to create it in exclusive mode as the first step of the command. If it already exists then backend needs to wait. So changing .auto settings would be

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

2012-11-08 Thread Amit Kapila
On Thursday, November 08, 2012 12:28 AM Tom Lane wrote: Robert Haas robertmh...@gmail.com writes: On Wed, Nov 7, 2012 at 12:29 PM, Tom Lane t...@sss.pgh.pa.us wrote: ... we don't normally read the config file within-commands, and there are both semantic and implementation problems to

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

2012-11-08 Thread Amit Kapila
On Thursday, November 08, 2012 5:24 AM Greg Smith wrote: On 11/2/12 11:17 AM, Magnus Hagander wrote: -Add a configuration subdirectory to the default installation. Needs to follow the config file location, so things like the Debian relocation of postgresql.conf still work.

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

2012-11-08 Thread Amit Kapila
On Thursday, November 08, 2012 8:07 PM Alvaro Herrera wrote: Amit Kapila escribió: 3. Two backends trying to write to .auto file we can use .auto.lock as the the lock by trying to create it in exclusive mode as the first step of the command. If it already exists then

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

2012-11-08 Thread Alvaro Herrera
Amit Kapila escribió: On Thursday, November 08, 2012 8:07 PM Alvaro Herrera wrote: The other way to define this would be to have a lock that you grab and keep until end of transaction, and the .auto.lock file is deleted if the transaction is aborted; so have the .auto.lock - .auto rename

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

2012-11-07 Thread Magnus Hagander
On Wed, Nov 7, 2012 at 5:19 AM, Amit Kapila amit.kap...@huawei.com wrote: On Tuesday, November 06, 2012 11:30 PM Robert Haas wrote: On Wed, Oct 31, 2012 at 8:17 AM, Magnus Hagander mag...@hagander.net wrote: I'm not convinced we ever *had* a consensus on this. There were proposals, but I'm

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

2012-11-07 Thread Tom Lane
Magnus Hagander mag...@hagander.net writes: On Wed, Nov 7, 2012 at 5:19 AM, Amit Kapila amit.kap...@huawei.com wrote: However there is one more point which I am not able to clearly make out is how to write into file that contains all configuration parameters changed by SQL. Perhaps you can

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

2012-11-07 Thread Magnus Hagander
On Wed, Nov 7, 2012 at 5:53 PM, Tom Lane t...@sss.pgh.pa.us wrote: Magnus Hagander mag...@hagander.net writes: On Wed, Nov 7, 2012 at 5:19 AM, Amit Kapila amit.kap...@huawei.com wrote: However there is one more point which I am not able to clearly make out is how to write into file that

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

2012-11-07 Thread Tom Lane
Magnus Hagander mag...@hagander.net writes: On Wed, Nov 7, 2012 at 5:53 PM, Tom Lane t...@sss.pgh.pa.us wrote: I'm not sure that the above approach works anyway --- for instance, the current setting might be a SET LOCAL result, in which case you still don't know anything about what the

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

2012-11-07 Thread Magnus Hagander
On Wed, Nov 7, 2012 at 6:19 PM, Tom Lane t...@sss.pgh.pa.us wrote: Magnus Hagander mag...@hagander.net writes: On Wed, Nov 7, 2012 at 5:53 PM, Tom Lane t...@sss.pgh.pa.us wrote: I'm not sure that the above approach works anyway --- for instance, the current setting might be a SET LOCAL result,

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

2012-11-07 Thread Tom Lane
Magnus Hagander mag...@hagander.net writes: On Wed, Nov 7, 2012 at 6:19 PM, Tom Lane t...@sss.pgh.pa.us wrote: You could dig it out of the stack if it's there, but that doesn't fix the race-condition aspect. Now a race is inevitable if two sessions try to set the *same* variable, but I think

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

2012-11-07 Thread Robert Haas
On Wed, Nov 7, 2012 at 12:29 PM, Tom Lane t...@sss.pgh.pa.us wrote: Magnus Hagander mag...@hagander.net writes: On Wed, Nov 7, 2012 at 6:19 PM, Tom Lane t...@sss.pgh.pa.us wrote: You could dig it out of the stack if it's there, but that doesn't fix the race-condition aspect. Now a race is

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

2012-11-07 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes: On Wed, Nov 7, 2012 at 12:29 PM, Tom Lane t...@sss.pgh.pa.us wrote: ... we don't normally read the config file within-commands, and there are both semantic and implementation problems to overcome if you want to do so. Why would you need to? It seems

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

2012-11-07 Thread Josh Berkus
Well, Magnus' proposed implementation supposed that the existing values *have* been loaded into the current session. I agree that with some locking and yet more code you could implement it without that. But this still doesn't seem to offer any detectable benefit over value-per-file. Well,

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

2012-11-07 Thread Robert Haas
On Wed, Nov 7, 2012 at 2:50 PM, Josh Berkus j...@agliodbs.com wrote: Well, Magnus' proposed implementation supposed that the existing values *have* been loaded into the current session. I agree that with some locking and yet more code you could implement it without that. But this still

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

2012-11-07 Thread Andres Freund
On Wed, Nov 07, 2012 at 03:15:07PM -0500, Robert Haas wrote: On Wed, Nov 7, 2012 at 2:50 PM, Josh Berkus j...@agliodbs.com wrote: Well, Magnus' proposed implementation supposed that the existing values *have* been loaded into the current session. I agree that with some locking and yet more

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

2012-11-07 Thread Greg Smith
On 11/2/12 11:17 AM, Magnus Hagander wrote: -Add a configuration subdirectory to the default installation. Needs to follow the config file location, so things like the Debian relocation of postgresql.conf still work. Maybe it has zero files; maybe it has one that's named for

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

2012-11-06 Thread Robert Haas
On Wed, Oct 31, 2012 at 8:17 AM, Magnus Hagander mag...@hagander.net wrote: I'm not convinced we ever *had* a consensus on this. There were proposals, but I'm not sure a majority ever bought into any one of 'em. I thought there was a consensus. But given that the one I thought we had

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

2012-11-06 Thread Amit Kapila
On Tuesday, November 06, 2012 11:30 PM Robert Haas wrote: On Wed, Oct 31, 2012 at 8:17 AM, Magnus Hagander mag...@hagander.net wrote: I'm not convinced we ever *had* a consensus on this. There were proposals, but I'm not sure a majority ever bought into any one of 'em. I thought there

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

2012-11-02 Thread Magnus Hagander
On Fri, Nov 2, 2012 at 2:19 AM, Greg Smith g...@2ndquadrant.com wrote: On 10/31/12 12:17 PM, Magnus Hagander wrote: The idea at the time was to use the include *directory* functionality, for say a config.d directory in pgdata. The builtin one would then use a predictable filename in this

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

2012-11-02 Thread Greg Stark
On Fri, Nov 2, 2012 at 1:19 AM, Greg Smith g...@2ndquadrant.com wrote: The idea at the time was to use the include *directory* functionality, for say a config.d directory in pgdata. The builtin one would then use a predictable filename in this directory, so that the DBA who prefers it can drop

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

2012-11-02 Thread Dimitri Fontaine
Andres Freund and...@2ndquadrant.com writes: I think it only really becomes viable with the introduction of directory includes where you can use one file per value. +1 -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers

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

2012-11-02 Thread Josh Berkus
-Add a configuration subdirectory to the default installation. Needs to follow the config file location, so things like the Debian relocation of postgresql.conf still work. Maybe it has zero files; maybe it has one that's named for this purpose, which defaults to the usual: # Don't edit

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

2012-11-01 Thread Amit kapila
On Wednesday, October 31, 2012 5:47 PM Magnus Hagander wrote: On Tue, Oct 30, 2012 at 11:24 PM, Tom Lane t...@sss.pgh.pa.us wrote: Josh Berkus j...@agliodbs.com writes: I should think that doing this requires heading back towards there being a single unique configuration stream, and over the

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

2012-11-01 Thread Greg Smith
On 10/31/12 12:17 PM, Magnus Hagander wrote: The idea at the time was to use the include *directory* functionality, for say a config.d directory in pgdata. The builtin one would then use a predictable filename in this directory, so that the DBA who prefers it can drop files both before and

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

2012-10-31 Thread Amit Kapila
On Wednesday, October 31, 2012 3:25 AM Josh Berkus I should think that doing this requires heading back towards there being a single unique configuration stream, and over the course of several versions, deprecating the INCLUDE directive. Oh, maybe I should take a closer look at Amit's

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

2012-10-31 Thread Magnus Hagander
On Tue, Oct 30, 2012 at 11:24 PM, Tom Lane t...@sss.pgh.pa.us wrote: Josh Berkus j...@agliodbs.com writes: I should think that doing this requires heading back towards there being a single unique configuration stream, and over the course of several versions, deprecating the INCLUDE directive.

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

2012-10-31 Thread Josh Berkus
Amit, I think you can simplify this task by forgetting about parsing the .auto file entirely when writing it. That is, the .auto file should be regenerated, and should write out whatever has been set in pg_settings, regardless of what was in the file beforehand. I don't see the value in parsing

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

2012-10-31 Thread Amit kapila
On Wednesday, October 31, 2012 10:21 PM Josh Berkus wrote: Amit, I think you can simplify this task by forgetting about parsing the .auto file entirely when writing it. That is, the .auto file should be regenerated, and should write out whatever has been set in pg_settings, regardless of

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

2012-10-30 Thread Josh Berkus
On 10/29/12 6:40 AM, Chris Corbyn wrote: What's the use case of this? It sounds like it will just create a maintenance nightmare where some stuff you expect to lookup in in postgresql.conf is actually hiding in the .auto file. Assuming only super users/sysadmins would have the ability to

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

2012-10-30 Thread Christopher Browne
On Tue, Oct 30, 2012 at 5:25 PM, Josh Berkus j...@agliodbs.com wrote: On 10/29/12 6:40 AM, Chris Corbyn wrote: What's the use case of this? It sounds like it will just create a maintenance nightmare where some stuff you expect to lookup in in postgresql.conf is actually hiding in the .auto

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

2012-10-30 Thread Josh Berkus
I should think that doing this requires heading back towards there being a single unique configuration stream, and over the course of several versions, deprecating the INCLUDE directive. Oh, maybe I should take a closer look at Amit's proposal then. I thought we planned to make use of the

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

2012-10-30 Thread Hannu Krosing
On 10/29/2012 03:14 PM, Amit Kapila wrote: On Monday, October 29, 2012 7:11 PM Chris Corbyn What's the use case of this? It sounds like it will just create a maintenance nightmare where some stuff you expect to lookup in in postgresql.conf is actually hiding in the .auto file. Assuming only

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

2012-10-30 Thread Andres Freund
On Tuesday, October 30, 2012 11:24:20 PM Tom Lane wrote: The fact that this isn't being done by a large number of people (is anybody at all actually doing it?) suggests to me that maybe the demand isn't all that great. It might also be that the idea of implementing that yourself is quite

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

2012-10-30 Thread Josh Berkus
Tom, I'm not convinced we ever *had* a consensus on this. There were proposals, but I'm not sure a majority ever bought into any one of 'em. The whole problem of intermixing manual editing and programmatic editing is just a big can of worms, and not everybody is prepared to give up the

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

2012-10-30 Thread Amit Kapila
On Wednesday, October 31, 2012 4:14 AM Josh Berkus wrote: Tom, I'm not convinced we ever *had* a consensus on this. There were proposals, but I'm not sure a majority ever bought into any one of 'em. The whole problem of intermixing manual editing and programmatic editing is just a

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

2012-10-30 Thread Amit Kapila
On Wednesday, October 31, 2012 3:58 AM Andres Freund wrote: On Tuesday, October 30, 2012 11:24:20 PM Tom Lane wrote: The fact that this isn't being done by a large number of people (is anybody at all actually doing it?) suggests to me that maybe the demand isn't all that great. It might

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

2012-10-30 Thread Amit Kapila
On Wednesday, October 31, 2012 3:32 AM Hannu Krosing wrote: On 10/29/2012 03:14 PM, Amit Kapila wrote: On Monday, October 29, 2012 7:11 PM Chris Corbyn What's the use case of this? It sounds like it will just create a maintenance nightmare where some stuff you expect to lookup in in

[HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL

2012-10-29 Thread Amit Kapila
SYNTAX: ALTER SYSTEM SET configuration_parameter = value COMMENT 'value'; DESIGN IDEA: (a) have a postgresql.conf.auto (b) add a default include for postgresql.conf.auto at the beginning of PostgreSQL.conf (c) SQL updates go to postgresql.conf.auto, which consists only ofsetting =

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

2012-10-29 Thread Merlin Moncure
On Mon, Oct 29, 2012 at 8:31 AM, Amit Kapila amit.kap...@huawei.com wrote: SYNTAX: ALTER SYSTEM SET configuration_parameter = value COMMENT 'value'; Comments/Suggestions about the value of this feature and Implementation Idea? How is this better than simply updating them through the

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

2012-10-29 Thread Chris Corbyn
What's the use case of this? It sounds like it will just create a maintenance nightmare where some stuff you expect to lookup in in postgresql.conf is actually hiding in the .auto file. Assuming only super users/sysadmins would have the ability to change things in the config file, wouldn't they

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

2012-10-29 Thread Amit Kapila
On Monday, October 29, 2012 7:06 PM Merlin Moncure wrote: On Mon, Oct 29, 2012 at 8:31 AM, Amit Kapila amit.kap...@huawei.com wrote: SYNTAX: ALTER SYSTEM SET configuration_parameter = value COMMENT 'value'; Comments/Suggestions about the value of this feature and Implementation

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

2012-10-29 Thread Amit Kapila
On Monday, October 29, 2012 7:11 PM Chris Corbyn What's the use case of this? It sounds like it will just create a maintenance nightmare where some stuff you expect to lookup in in postgresql.conf is actually hiding in the .auto file. Assuming only super users/sysadmins would have the

<    1   2   3   4