Hello Peter
I am looking on your patch.
I found only one issue
in documentation is role name or keyword ALL marked as optional, but
it is mandatory
+ALTER ROLE [ replaceable class=PARAMETERname/replaceable | ALL
] [ IN DATABASE replaceable
class=PARAMETERdatabase_name/replaceable ] SET
On 11/15/12 12:53 PM, Peter Eisentraut wrote:
We already have the ability to store in pg_db_role_setting configuration
settings for
specific user, specific database
specific user, any database
any user, specific database
The existing infrastructure would also support
any user, any
On Saturday, November 17, 2012 3:35 AM Dimitri Fontaine wrote:
Tom Lane t...@sss.pgh.pa.us writes:
Have you considered ALTER SYSTEM SET ... ? We'd talked about that in
the context of the other patch, but it seems to fit much more
naturally
with this one. Or maybe ALTER GLOBAL SET or
On Fri, Nov 16, 2012 at 2:53 AM, Peter Eisentraut pete...@gmx.net wrote:
Independent of the discussion of how to edit configuration files from
SQL, I had another idea how many of the use cases for this could be handled.
We already have the ability to store in pg_db_role_setting configuration
On 11/15/2012 11:38 PM, Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
On Thu, Nov 15, 2012 at 6:53 PM, Peter Eisentraut pete...@gmx.net wrote:
The only thing you couldn't handle that way are SIGHUP settings, but the
often-cited use cases work_mem, logging, etc. would work.
How
On 16-11-2012 12:27, Hannu Krosing wrote:
Why not just make the sending SIGHUP a separate command as it is now ?
SELECT pg_reload_config();
... or even a RELOAD command. I've already coded a WIP patch for such command.
--
Euler Taveira de Oliveira - Timbira
On 11/15/12 12:53 PM, Peter Eisentraut wrote:
All you'd need is to add
ApplySetting(InvalidOid, InvalidOid, relsetting, PGC_S_$SOMETHING);
in postinit.c, and have some SQL command to modify this setting.
Alright, any suggestions for the syntax? We currently have
ALTER DATABASE ... SET
On 16-11-2012 12:59, Peter Eisentraut wrote:
Another way might be something like
SET GLOBAL name = value
That's the exact syntax I'm about to propose for this feature (changing
settings using SQL).
Are you thinking about allowing changing all configuration settings or just a
subset of it?
Peter Eisentraut pete...@gmx.net writes:
Another way might be something like
SET GLOBAL name = value
but that would make the command very dissimilar from the other ones,
even though their effects are closely related.
Yeah. I think it would also give people a wrong impression about when
the
On Thu, Nov 15, 2012 at 5:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Another and probably bigger thing is that SIGHUP is used for settings
that do something useful only in background processes (eg checkpointer).
Some of those processes are not capable of reading system catalogs at
all. This is
On 11/16/2012 06:05 PM, Robert Haas wrote:
On Thu, Nov 15, 2012 at 5:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Another and probably bigger thing is that SIGHUP is used for settings
that do something useful only in background processes (eg checkpointer).
Some of those processes are not capable
Hannu Krosing ha...@krosing.net writes:
Can't we keep a separate text .conf file specifically for the background
processes which can't read system catalogs. It could contain only the
GUCs these processes are interested in.
What's the value of that, compared to the existing proposal for
Tom Lane t...@sss.pgh.pa.us writes:
Have you considered ALTER SYSTEM SET ... ? We'd talked about that in
the context of the other patch, but it seems to fit much more naturally
with this one. Or maybe ALTER GLOBAL SET or ALTER ALL SET.
I would paint that one ALTER SYSTEM SET and the file
Independent of the discussion of how to edit configuration files from
SQL, I had another idea how many of the use cases for this could be handled.
We already have the ability to store in pg_db_role_setting configuration
settings for
specific user, specific database
specific user, any database
On Thu, Nov 15, 2012 at 12:53 PM, Peter Eisentraut pete...@gmx.net wrote:
Independent of the discussion of how to edit configuration files from
SQL, I had another idea how many of the use cases for this could be handled.
We already have the ability to store in pg_db_role_setting configuration
Le jeudi 15 novembre 2012 18:53:15, Peter Eisentraut a écrit :
Independent of the discussion of how to edit configuration files from
SQL, I had another idea how many of the use cases for this could be
handled.
We already have the ability to store in pg_db_role_setting configuration
settings
ApplySetting(InvalidOid, InvalidOid, relsetting, PGC_S_$SOMETHING);
in postinit.c, and have some SQL command to modify this setting.
The only thing you couldn't handle that way are SIGHUP settings, but the
often-cited use cases work_mem, logging, etc. would work.
There would also be
Peter Eisentraut pete...@gmx.net writes:
The existing infrastructure would also support
any user, any database (= all the time)
There would also be the advantage that pg_dumpall would save these settings.
Thoughts?
That's brilliant. +1.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr
On Thu, Nov 15, 2012 at 6:53 PM, Peter Eisentraut pete...@gmx.net wrote:
Independent of the discussion of how to edit configuration files from
SQL, I had another idea how many of the use cases for this could be handled.
We already have the ability to store in pg_db_role_setting configuration
Magnus Hagander mag...@hagander.net writes:
On Thu, Nov 15, 2012 at 6:53 PM, Peter Eisentraut pete...@gmx.net wrote:
The only thing you couldn't handle that way are SIGHUP settings, but the
often-cited use cases work_mem, logging, etc. would work.
How hard would it be to make it work for
On 11/16/2012 02:38 AM, Josh Berkus wrote:
ApplySetting(InvalidOid, InvalidOid, relsetting, PGC_S_$SOMETHING);
in postinit.c, and have some SQL command to modify this setting.
The only thing you couldn't handle that way are SIGHUP settings, but the
often-cited use cases work_mem, logging,
21 matches
Mail list logo
