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 [ name | ALL
] [ IN DATABASE database_name ] SET
configuration_parameter FROM CURRENT
+ALTER ROLE [ name | ALL
] [ IN DATABASE database
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
On Fri, Nov 16, 2012 at 2:53 AM, Peter Eisentraut 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
> settings fo
On Saturday, November 17, 2012 3:35 AM Dimitri Fontaine wrote:
> Tom Lane 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.
Tom Lane 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 based one ALTER
CON
Hannu Krosing 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
write-a-text-file-dire
On 11/16/2012 06:05 PM, Robert Haas wrote:
On Thu, Nov 15, 2012 at 5:38 PM, Tom Lane 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 ca
On Thu, Nov 15, 2012 at 5:38 PM, Tom Lane 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 particularly a
Peter Eisentraut 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 setting would
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
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 ... SE
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 http://www.timbira.
On 11/15/2012 11:38 PM, Tom Lane wrote:
Magnus Hagander writes:
On Thu, Nov 15, 2012 at 6:53 PM, Peter Eisentraut 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,
Magnus Hagander writes:
> On Thu, Nov 15, 2012 at 6:53 PM, Peter Eisentraut 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 SIGHUP?
One issue is that pg_db_
On Thu, Nov 15, 2012 at 6:53 PM, Peter Eisentraut 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
> settings fo
Peter Eisentraut 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 Postgre
> 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 als
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
> set
On Thu, Nov 15, 2012 at 12:53 PM, Peter Eisentraut 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
> settings f
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
any
21 matches
Mail list logo
