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
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:
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
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
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
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'
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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:
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,
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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,
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
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
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
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,
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
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
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
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
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
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
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
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
-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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
301 - 379 of 379 matches
Mail list logo
