Hi,
Magnus Hagander wrote:
...
Can you explain why this wouldn't be usable?
Because you will end up with an ever-growing file, that will be a PITA to
deal with. Consider it after 10k+ changes. (yes, I can see that happening.
You know how some people use GUIs) Or 100k. The problem does not happ
Mark Woodward wrote:
Mark Woodward wrote:
I have been looking at this thread for a bit and want to interject an
idea.
A couple years ago, I offered a patch to the GUC system that added a
number of abilities, two left out were:
(1) Specify a configuration file on the command line.
(2) Al
>
>
> Mark Woodward wrote:
>> I have been looking at this thread for a bit and want to interject an
>> idea.
>>
>> A couple years ago, I offered a patch to the GUC system that added a
>> number of abilities, two left out were:
>>
>> (1) Specify a configuration file on the command line.
>> (2) Allow
Mark Woodward wrote:
I have been looking at this thread for a bit and want to interject an idea.
A couple years ago, I offered a patch to the GUC system that added a
number of abilities, two left out were:
(1) Specify a configuration file on the command line.
(2) Allow the inclusion of a conf
I have been looking at this thread for a bit and want to interject an idea.
A couple years ago, I offered a patch to the GUC system that added a
number of abilities, two left out were:
(1) Specify a configuration file on the command line.
(2) Allow the inclusion of a configuration file from withi
Magnus Hagander wrote:
> If they don't have an actual database, it's fairly common to use SQLite or
> similar just to get proper database storage for it.
With all the concern about parsing in this thread, perhaps it's best
if this config-overrides file not be of the same syntax as postgresql.conf
Joshua D. Drake napsal(a):
Zdenek Kotala wrote:
I like this idea. By my opinion only GUC variable with PGC_POSTMASTER
context must be in postgresql.conf. Most of them are related to memory
and networking configuration. Other can be only store in database. And
for startup, default value will w
Zdenek Kotala wrote:
I like this idea. By my opinion only GUC variable with PGC_POSTMASTER
context must be in postgresql.conf. Most of them are related to memory
and networking configuration. Other can be only store in database. And
for startup, default value will work pretty well.
By the wa
Joshua D. Drake napsal(a):
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 19 Feb 2008 15:22:42 -0300
Alvaro Herrera <[EMAIL PROTECTED]> wrote:
Joshua D. Drake wrote:
IMO this should all be in the database and that's it. The idea that
our global settings are in a file seems unusual con
>>> On Wed, Feb 20, 2008 at 5:02 PM, in message
<[EMAIL PROTECTED]>, "Josh Berkus" <[EMAIL PROTECTED]> wrote:
> imagine you're adminning 250 PostgreSQL servers backing a
> social networking application. You decide the application needs a
> higher default sort_mem for all new connections, on all
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> Do you know of any cross-platform tool that is capable of dealing with the
> PostgreSQL configuration file in a context sensitive manner? Meaning that
> it doesn't just treat it as a big file, but you can actually do "for all
> these 32 server
On Thu, 21 Feb 2008 10:30:00 +0100
Magnus Hagander <[EMAIL PROTECTED]> wrote:
> Do you know of any cross-platform tool that is capable of dealing with the
> PostgreSQL configuration file in a context sensitive manner? Meaning that
> it doesn't just treat it as a big file, but you can actually do "f
* Magnus Hagander <[EMAIL PROTECTED]> [080221 04:30]:
> > I would have thought that any "larger enterprise" was familiar with
> > these approaches, and are probably using them already to
> > manage/configure there general unix environments
> What makes you think that all environments are unix env
Magnus Hagander wrote:
On Wed, Feb 20, 2008 at 06:14:27PM -0800, Joshua D. Drake wrote:
On Wed, 20 Feb 2008 09:42:02 -0500
Andrew Dunstan <[EMAIL PROTECTED]> wrote:
All this discussion seems to me to be going off into the clouds,
where every objection is met with some still more elaborate sche
Aidan Van Dyk wrote:
> * Magnus Hagander <[EMAIL PROTECTED]> [080220 14:03]:
>
> > > I think the first step is really for some people to show code that
> > > "rewrites" the config file changing a setting reliably and correctly.
> >
> > But what we're donig now is discussing *how to do that*, no?
On Wed, Feb 20, 2008 at 03:02:49PM -0800, Josh Berkus wrote:
> All,
>
> I think we're failing to discuss the primary use-case for this, which
> is one reason why the solutions aren't obvious.
>
> And that use case is: multi-server management.
I don't agree that this is the primary use case. But I
On Wed, Feb 20, 2008 at 06:17:37PM -0500, Aidan Van Dyk wrote:
> * Josh Berkus <[EMAIL PROTECTED]> [080220 18:00]:
> > All,
> >
> > I think we're failing to discuss the primary use-case for this, which
> > is one reason why the solutions aren't obvious.
>
> > However, imagine you're adminning 25
On Wed, Feb 20, 2008 at 06:14:27PM -0800, Joshua D. Drake wrote:
> On Wed, 20 Feb 2008 09:42:02 -0500
> Andrew Dunstan <[EMAIL PROTECTED]> wrote:
>
> > All this discussion seems to me to be going off into the clouds,
> > where every objection is met with some still more elaborate scheme. I
> > thi
On Wed, Feb 20, 2008 at 11:53:47PM +, Gregory Stark wrote:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>
> > Andrew Dunstan <[EMAIL PROTECTED]> writes:
> >> All this discussion seems to me to be going off into the clouds, where
> >> every objection is met with some still more elaborate scheme. I
On Wed, Feb 20, 2008 at 03:56:38PM -0800, paul rivers wrote:
> Tom Lane wrote:
> >Aidan Van Dyk <[EMAIL PROTECTED]> writes:
> >
> >>* Josh Berkus <[EMAIL PROTECTED]> [080220 18:00]:
> >>
> >>>We need a server-based tool for the manipulating postgresql.conf, and
> >>>one which is network-acces
On Wed, Feb 20, 2008 at 06:38:10PM -0500, Tom Lane wrote:
> Aidan Van Dyk <[EMAIL PROTECTED]> writes:
> > * Josh Berkus <[EMAIL PROTECTED]> [080220 18:00]:
> >> We need a server-based tool for the manipulating postgresql.conf, and
> >> one which is network-accessable, allows updating individual set
On Wed, Feb 20, 2008 at 06:38:09PM -0500, Bruce Momjian wrote:
> Aidan Van Dyk wrote:
> > * Josh Berkus <[EMAIL PROTECTED]> [080220 18:00]:
> > > All,
> > >
> > > I think we're failing to discuss the primary use-case for this, which
> > > is one reason why the solutions aren't obvious.
> >
> > >
On 21/02/2008, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
> On Wed, 20 Feb 2008 23:02:34 -0500
> Aidan Van Dyk <[EMAIL PROTECTED]> wrote:
>
> > * Joshua D. Drake <[EMAIL PROTECTED]> [080220 21:15]:
> >
> > > The one thing this does is make the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 20 Feb 2008 23:02:34 -0500
Aidan Van Dyk <[EMAIL PROTECTED]> wrote:
> * Joshua D. Drake <[EMAIL PROTECTED]> [080220 21:15]:
>
> > The one thing this does is make the postgresql.conf basically a
> > placeholder. It is not definitive anymore,
* Joshua D. Drake <[EMAIL PROTECTED]> [080220 21:15]:
> The one thing this does is make the postgresql.conf basically a
> placeholder. It is not definitive anymore, in the sense that settings
> will be overwritten on restart. That really isn't that uncommon anyway
> in other applications.
Man, I
Tom Lane wrote:
Josh Berkus <[EMAIL PROTECTED]> writes:
The problem I've constantly run into with parsing and modifying settings
in a user-edited postgresql.conf file is that sometimes users do their
own chronological documentation:
[snip]
Yeah, those are good examples. It would b
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 20 Feb 2008 09:42:02 -0500
Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> All this discussion seems to me to be going off into the clouds,
> where every objection is met with some still more elaborate scheme. I
> think we need to look at simple,
On Thu, Feb 21, 2008 at 12:02 AM, Josh Berkus <[EMAIL PROTECTED]> wrote:
> All,
>
> I think we're failing to discuss the primary use-case for this, which
> is one reason why the solutions aren't obvious.
>
> And that use case is: multi-server management.
...and third-party management solutions.
Tom Lane wrote:
Aidan Van Dyk <[EMAIL PROTECTED]> writes:
* Josh Berkus <[EMAIL PROTECTED]> [080220 18:00]:
We need a server-based tool for the manipulating postgresql.conf, and
one which is network-accessable, allows updating individual settings,
Do we need to develop our
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>> All this discussion seems to me to be going off into the clouds, where
>> every objection is met with some still more elaborate scheme. I think we
>> need to look at simple, incremental, and if possible backwa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 20 Feb 2008 18:38:10 -0500
Tom Lane <[EMAIL PROTECTED]> wrote:
> Aidan Van Dyk <[EMAIL PROTECTED]> writes:
> > * Josh Berkus <[EMAIL PROTECTED]> [080220 18:00]:
> >> We need a server-based tool for the manipulating postgresql.conf,
> >> and on
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 20 Feb 2008 18:38:09 -0500 (EST)
Bruce Momjian <[EMAIL PROTECTED]> wrote:
> Agreed. Put postgresql.conf on an NFS server and restart the servers.
>
Bruce, that is insane.
Sincerely,
Joshua D. Drake
- --
The PostgreSQL Company since 1997
Aidan Van Dyk wrote:
-- Start of PGP signed section.
> * Josh Berkus <[EMAIL PROTECTED]> [080220 18:00]:
> > All,
> >
> > I think we're failing to discuss the primary use-case for this, which
> > is one reason why the solutions aren't obvious.
>
> > However, imagine you're adminning 250 PostgreS
Aidan Van Dyk <[EMAIL PROTECTED]> writes:
> * Josh Berkus <[EMAIL PROTECTED]> [080220 18:00]:
>> We need a server-based tool for the manipulating postgresql.conf, and
>> one which is network-accessable, allows updating individual settings,
> Do we need to develop our own set of "remote management"
* Josh Berkus <[EMAIL PROTECTED]> [080220 18:00]:
> All,
>
> I think we're failing to discuss the primary use-case for this, which
> is one reason why the solutions aren't obvious.
> However, imagine you're adminning 250 PostgreSQL servers backing a
> social networking application. You decide t
All,
I think we're failing to discuss the primary use-case for this, which
is one reason why the solutions aren't obvious.
And that use case is: multi-server management.
PostgreSQL is *easy* to manage on one server. For a single server, the
existing text file editor GUIs are clunky but good eno
On Wed, Feb 20, 2008 at 7:34 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Josh Berkus <[EMAIL PROTECTED]> writes:
>
> > 2) allow *commenting* of pg_settings / SET PERMANENT. Thus:
>
> > SET PERMANENT work_mem = '12mb' COMMENT '16mb too high; OOM';
>
> Ugh :-(
>
> I think that putting this into SET
Tom Lane wrote:
Magnus Hagander <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
No you don't. All you need is the output of the pg_settings view.
Or at least, if that's insufficient, let's discuss exactly how.
I can read the settings. How do I write them, if the only interface to
write them is
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> No you don't. All you need is the output of the pg_settings view.
>> Or at least, if that's insufficient, let's discuss exactly how.
> I can read the settings. How do I write them, if the only interface to
> write them is to deal w
Tom Lane wrote:
Magnus Hagander <[EMAIL PROTECTED]> writes:
On Wed, Feb 20, 2008 at 01:43:46PM -0500, Tom Lane wrote:
The main part of that is the GUI, which is certainly not going to be in
the server, so I fail to see exactly what you think you're really
gaining.
The way things are now, wri
Magnus Hagander <[EMAIL PROTECTED]> writes:
> On Wed, Feb 20, 2008 at 01:43:46PM -0500, Tom Lane wrote:
>> The main part of that is the GUI, which is certainly not going to be in
>> the server, so I fail to see exactly what you think you're really
>> gaining.
> The way things are now, writing the
* Magnus Hagander <[EMAIL PROTECTED]> [080220 14:03]:
> > I think the first step is really for some people to show code that
> > "rewrites" the config file changing a setting reliably and correctly.
>
> But what we're donig now is discussing *how to do that*, no?
Sort of, but of course, we're ge
On Wed, Feb 20, 2008 at 01:55:05PM -0500, Aidan Van Dyk wrote:
> * Joshua D. Drake <[EMAIL PROTECTED]> [080220 13:43]:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > On Wed, 20 Feb 2008 13:27:25 -0500
> > Tom Lane <[EMAIL PROTECTED]> wrote:
> >
> > > For the point-and-drool crowd t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 20 Feb 2008 13:55:05 -0500
Aidan Van Dyk <[EMAIL PROTECTED]> wrote:
> Once we have people comfortable with it rewriting the file, the
> bikeshedding can start as to how to "use" it through the SQL
> interface.
>
> But, until there's code out
On Wed, Feb 20, 2008 at 01:43:46PM -0500, Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > On Wed, Feb 20, 2008 at 01:27:25PM -0500, Tom Lane wrote:
> >> For the point-and-drool crowd that can't cope with editing a text file,
> >> perhaps the best avenue to having a GUI is to build
* Joshua D. Drake <[EMAIL PROTECTED]> [080220 13:43]:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Wed, 20 Feb 2008 13:27:25 -0500
> Tom Lane <[EMAIL PROTECTED]> wrote:
>
> > For the point-and-drool crowd that can't cope with editing a text
>
> *ahem*
>
> I am far form a point and d
Magnus Hagander <[EMAIL PROTECTED]> writes:
> On Wed, Feb 20, 2008 at 01:27:25PM -0500, Tom Lane wrote:
>> For the point-and-drool crowd that can't cope with editing a text file,
>> perhaps the best avenue to having a GUI is to build it atop the
>> just-mentioned facility, namely
>>
>> 1. suck out
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 20 Feb 2008 13:27:25 -0500
Tom Lane <[EMAIL PROTECTED]> wrote:
> For the point-and-drool crowd that can't cope with editing a text
*ahem*
I am far form a point and drool person and I am telling you:
SET PERMANENTLY work_mem TO 65MB ;
Is a
On Wed, Feb 20, 2008 at 01:27:25PM -0500, Tom Lane wrote:
> Josh Berkus <[EMAIL PROTECTED]> writes:
> > The problem I've constantly run into with parsing and modifying settings
> > in a user-edited postgresql.conf file is that sometimes users do their
> > own chronological documentation:
> > [sni
Josh Berkus <[EMAIL PROTECTED]> writes:
> 2) allow *commenting* of pg_settings / SET PERMANENT. Thus:
> SET PERMANENT work_mem = '12mb' COMMENT '16mb too high; OOM';
Ugh :-(
I think that putting this into SET is a pretty bad idea in any case.
SET is, and always has been, a session-local operati
Josh Berkus <[EMAIL PROTECTED]> writes:
> The problem I've constantly run into with parsing and modifying settings
> in a user-edited postgresql.conf file is that sometimes users do their
> own chronological documentation:
> [snip]
Yeah, those are good examples. It would be fairly easy to deal
Magnus, all:
Other thoughts:
1) fix category display for pg_settings. 'nuff said.
2) allow *commenting* of pg_settings / SET PERMANENT. Thus:
SET PERMANENT work_mem = '12mb' COMMENT '16mb too high; OOM';
SET
SELECT name, comment FROM pg_settings WHERE name = 'work_mem';
work_mem| 16
Tom,
The SQL-exposed function knows how to find and replace the definition
of a variable (commented or otherwise) in the primary configuration
file. It does not chase INCLUDEs. If it doesn't find the target
variable anyplace in the primary file, it errors out.
Hmmm. I guess I'm just not goo
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> All this discussion seems to me to be going off into the clouds, where
> every objection is met with some still more elaborate scheme. I think we
> need to look at simple, incremental, and if possible backwards
> compatible changes.
+1. Let me propo
Le mercredi 20 février 2008, Andrew Dunstan a écrit :
> No. Seriously. We need to have reasonable manual editability preserved
> for all cases. The tree of files proposal just strikes me as a basic
> non-starter, and, frankly, a piece of bad design. If you need structure,
> then using the file syst
Dimitri Fontaine wrote:
Le mercredi 20 février 2008, Magnus Hagander a écrit :
What about having a postgresql.conf.d directory containing a file per
setting, maybe with a subdir per section. If I take Josh Berkus example,
we'd have
IMHO, if we do that it really sucks for those who
Le mercredi 20 février 2008, Magnus Hagander a écrit :
> > What about having a postgresql.conf.d directory containing a file per
> > setting, maybe with a subdir per section. If I take Josh Berkus example,
> > we'd have
>
>
> IMHO, if we do that it really sucks for those who use manual configurati
On Wed, Feb 20, 2008 at 10:20:55AM -0300, Alvaro Herrera wrote:
> Magnus Hagander escribió:
> > On Wed, Feb 20, 2008 at 09:36:43AM -0300, Alvaro Herrera wrote:
>
> > > IMO restart-only settings should not be changeable via the new SQL
> > > command. It's just too messy to deal with that.
> >
> >
Magnus Hagander escribió:
> On Wed, Feb 20, 2008 at 09:36:43AM -0300, Alvaro Herrera wrote:
> > IMO restart-only settings should not be changeable via the new SQL
> > command. It's just too messy to deal with that.
>
> I respectfully disagree. It should be settable. You need a restart, sure,
> a
On Wed, Feb 20, 2008 at 09:36:43AM -0300, Alvaro Herrera wrote:
> Dawid Kuroczko escribió:
>
> > 1) changes that cannot be done to live server:
> >
> > SET PERMANENT shared_buffers = '1GB';
> >
> > Now, this is a setting that cannot be changed "live", but it should be
> > changeable. And we nee
Dawid Kuroczko escribió:
> 1) changes that cannot be done to live server:
>
> SET PERMANENT shared_buffers = '1GB';
>
> Now, this is a setting that cannot be changed "live", but it should be
> changeable. And we need a command to query what's permanent
> and what's current.
IMO restart-only se
On Wed, Feb 20, 2008 at 11:20:29AM +0100, Dimitri Fontaine wrote:
> Le mardi 19 février 2008, Gregory Stark a écrit :
> > "Magnus Hagander" <[EMAIL PROTECTED]> writes:
> > > Yeah, that may actually be a very good way to implement it. I don't like
> > > the idea of continously appending to an existi
Le mardi 19 février 2008, Gregory Stark a écrit :
> "Magnus Hagander" <[EMAIL PROTECTED]> writes:
> > Yeah, that may actually be a very good way to implement it. I don't like
> > the idea of continously appending to an existing file, but if we did have
> > a separate file with a tightly controlled
On Feb 19, 2008 10:31 PM, Josh Berkus <[EMAIL PROTECTED]> wrote:
> Magnus, All,
>
> This is something I've been thinking about too, just because my efforts to
> write auto-config scripts have gotten bogged down in the need to parse and
> write .conf files in a paltform-agnostic way and preserve com
On Tue, Feb 19, 2008 at 11:27:47PM -0500, Robert Treat wrote:
> On Tuesday 19 February 2008 20:08, Tom Lane wrote:
> > Josh Berkus <[EMAIL PROTECTED]> writes:
> > > On Tuesday 19 February 2008 15:05, Bruce Momjian wrote:
> > >> One idea would be to remove duplicate postgresql.conf appended entries
On Tue, Feb 19, 2008 at 02:59:44PM -0800, Josh Berkus wrote:
> Magnus,
>
> > That's basically "include" but with a different name, no?
>
> Yes. FWIW, I seem to be lagged about 3 hours on -hackers.
>
> > Why do you need to split it in two columns, and what would go in what
> > column?
>
> Curr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Feb 19, 2008 at 04:38:16PM +0100, Csaba Nagy wrote:
> > Are you suggesting we keep appending? So if I set the same parameter 100
> > times, it would show up on 100 rows?
>
> What about not touching the config file at all, but write to a separa
On Tuesday 19 February 2008 20:08, Tom Lane wrote:
> Josh Berkus <[EMAIL PROTECTED]> writes:
> > On Tuesday 19 February 2008 15:05, Bruce Momjian wrote:
> >> One idea would be to remove duplicate postgresql.conf appended entries
> >> on server start.
> >
> > I think anything which has us appending
On Tuesday 19 February 2008 14:32, Andrew Dunstan wrote:
> Andrew Dunstan wrote:
> > Alvaro Herrera wrote:
> >> Joshua D. Drake wrote:
> >>> IMO this should all be in the database and that's it. The idea that our
> >>> global settings are in a file seems unusual consider we have a
> >>> perfectly g
Josh Berkus <[EMAIL PROTECTED]> writes:
> On Tuesday 19 February 2008 15:05, Bruce Momjian wrote:
>> One idea would be to remove duplicate postgresql.conf appended entries
>> on server start.
> I think anything which has us appending extra settings to the end of the
> file is a non-starter. We'd
On Tuesday 19 February 2008 15:05, Bruce Momjian wrote:
> One idea would be to remove duplicate postgresql.conf appended entries
> on server start.
I think anything which has us appending extra settings to the end of the
file is a non-starter. We'd get "I changed the setting, but nothing's
happ
One idea would be to remove duplicate postgresql.conf appended entries
on server start.
---
Josh Berkus wrote:
> Magnus,
>
> > That's basically "include" but with a different name, no?
>
> Yes. FWIW, I seem to be lagged a
Magnus,
> That's basically "include" but with a different name, no?
Yes. FWIW, I seem to be lagged about 3 hours on -hackers.
> Why do you need to split it in two columns, and what would go in what
> column?
Current data:
postgres=# select name, category from pg_settings;
name
On Tue, 2008-02-19 at 13:31 -0800, Josh Berkus wrote:
> Magnus, All,
>
> This is something I've been thinking about too, just because my efforts to
> write auto-config scripts have gotten bogged down in the need to parse and
> write .conf files in a paltform-agnostic way and preserve comments.
Magnus, All,
This is something I've been thinking about too, just because my efforts to
write auto-config scripts have gotten bogged down in the need to parse and
write .conf files in a paltform-agnostic way and preserve comments. I
agree with Magnus that it's something we need to address. Ha
On Tue, 2008-02-19 at 19:38 +, Gregory Stark wrote:
> "Magnus Hagander" <[EMAIL PROTECTED]> writes:
>
> > On Tue, Feb 19, 2008 at 04:58:21PM +, Gregory Stark wrote:
> >
> >> The include file method is workable but isn't perfect. What happens if a
> >> user
> >> connects with pgadmin and
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> On Tue, Feb 19, 2008 at 04:58:21PM +, Gregory Stark wrote:
>
>> The include file method is workable but isn't perfect. What happens if a user
>> connects with pgadmin and changes a parameter but that parameter is
>> overridden
>> by a variable i
Andrew Dunstan wrote:
Alvaro Herrera wrote:
Joshua D. Drake wrote:
IMO this should all be in the database and that's it. The idea that our
global settings are in a file seems unusual consider we have a
perfectly good storage engine available.
That doesn't work, because many settin
On Tue, Feb 19, 2008 at 04:58:21PM +, Gregory Stark wrote:
> "Magnus Hagander" <[EMAIL PROTECTED]> writes:
>
> > Yeah, that may actually be a very good way to implement it. I don't like
> > the idea of continously appending to an existing file, but if we did have a
> > separate file with a tig
On Tue, Feb 19, 2008 at 02:19:16PM -0300, Alvaro Herrera wrote:
> Gregory Stark wrote:
>
> > The alternative is to have two files and read them both. Then if you change
> > a
> > variable which is overridden by the other source you can warn that the
> > change
> > is ineffective.
> >
> > I thin
Alvaro Herrera wrote:
Joshua D. Drake wrote:
IMO this should all be in the database and that's it. The idea that our
global settings are in a file seems unusual consider we have a
perfectly good storage engine available.
That doesn't work, because many settings must be loaded before
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 19 Feb 2008 15:22:42 -0300
Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Joshua D. Drake wrote:
>
> > IMO this should all be in the database and that's it. The idea that
> > our global settings are in a file seems unusual consider we have a
> >
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> IMO this should all be in the database and that's it. The idea that our
> global settings are in a file seems unusual consider we have a
> perfectly good storage engine available.
The sufficient reason why not is that many of these settings must be
a
Joshua D. Drake wrote:
> IMO this should all be in the database and that's it. The idea that our
> global settings are in a file seems unusual consider we have a
> perfectly good storage engine available.
That doesn't work, because many settings must be loaded before the
database is fully operati
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 19 Feb 2008 15:36:26 +0100
Magnus Hagander <[EMAIL PROTECTED]> wrote:
> Currently, pgAdmin supports editing postgresql.conf remotely using the
> adminpack to open the file, change it locally in memory, and using the
> adminpack again to write
>
> Gregory Stark wrote:
>
> > The alternative is to have two files and read them both. Then if you
> change a
> > variable which is overridden by the other source you can warn that
the
> change
> > is ineffective.
> >
> > I think on balance the include file method is so much simpler that I
> pre
Gregory Stark wrote:
> The alternative is to have two files and read them both. Then if you change a
> variable which is overridden by the other source you can warn that the change
> is ineffective.
>
> I think on balance the include file method is so much simpler that I prefer
> it.
I think th
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> Yeah, that may actually be a very good way to implement it. I don't like
> the idea of continously appending to an existing file, but if we did have a
> separate file with a tightly controlled format that would be doable.
+1
Separating the automati
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> What I'd really like to see is something like a new keyword on the SET
> command, so you could to SET PERMANENT foo=bar, which would write the
> configuration back into postgresql.conf.
FWIW, I made a Pl/PerlU function that did this at one po
On Tue, Feb 19, 2008 at 11:14:59AM -0500, Andrew Dunstan wrote:
>
>
> Richard Huxton wrote:
> >Magnus Hagander wrote:
> >>
> >>Right. I don't think we have any settings that depend on order, do we?
> >
> >That's what I was trying to think of - nothing came to mind.
> >
>
> custom_variable_classe
On Tue, Feb 19, 2008 at 11:09:43AM -0500, Aidan Van Dyk wrote:
> * Magnus Hagander <[EMAIL PROTECTED]> [080219 10:39]:
> > On Tue, Feb 19, 2008 at 10:34:26AM -0500, Aidan Van Dyk wrote:
> > > > Are you suggesting we keep appending? So if I set the same parameter 100
> > > > times, it would show up
Richard Huxton wrote:
Magnus Hagander wrote:
Right. I don't think we have any settings that depend on order, do we?
That's what I was trying to think of - nothing came to mind.
custom_variable_classes and dependents?
cheers
andrew
---(end of broadcast)-
On Tue, Feb 19, 2008 at 11:11:05AM -0500, Aidan Van Dyk wrote:
> * Csaba Nagy <[EMAIL PROTECTED]> [080219 10:59]:
> > > Are you suggesting we keep appending? So if I set the same parameter 100
> > > times, it would show up on 100 rows?
> >
> > What about not touching the config file at all, but wr
Aidan Van Dyk wrote:
Any "set permanent" settings should be *appended* to the main config
file, preferably with a comment line, like:
# Set by user from client on
some_guc option = some_value
Are you suggesting we keep appending? So if I set the same parameter 100
tim
* Csaba Nagy <[EMAIL PROTECTED]> [080219 10:59]:
> > Are you suggesting we keep appending? So if I set the same parameter 100
> > times, it would show up on 100 rows?
>
> What about not touching the config file at all, but write to a separate
> file which is completely under the control of postgre
* Magnus Hagander <[EMAIL PROTECTED]> [080219 10:39]:
> On Tue, Feb 19, 2008 at 10:34:26AM -0500, Aidan Van Dyk wrote:
> > > Are you suggesting we keep appending? So if I set the same parameter 100
> > > times, it would show up on 100 rows?
> >
> > In my opinion, absolutely. It's easy, safe, and
Magnus Hagander wrote:
On Tue, Feb 19, 2008 at 03:53:11PM +, Richard Huxton wrote:
Magnus Hagander wrote:
What I'd really like to see is something like a new keyword on the SET
command, so you could to SET PERMANENT foo=bar, which would write the
configuration back into postgresql.conf.
I
On Tue, Feb 19, 2008 at 03:53:11PM +, Richard Huxton wrote:
> Magnus Hagander wrote:
> >What I'd really like to see is something like a new keyword on the SET
> >command, so you could to SET PERMANENT foo=bar, which would write the
> >configuration back into postgresql.conf.
> >
> >I don't have
On Tue, 2008-02-19 at 16:41 +0100, Magnus Hagander wrote:
> The end result wouldn't be "as clean" as some would expect, but it would
> certainly be easier code-wise. For example, I'm sure someone would get the
> suggestion to go edit postgresql.conf to change a config value, and be
> surprised when
Magnus Hagander wrote:
What I'd really like to see is something like a new keyword on the SET
command, so you could to SET PERMANENT foo=bar, which would write the
configuration back into postgresql.conf.
I don't have a complete solution for how to actually implement it, so I'm
just throwing out
1 - 100 of 108 matches
Mail list logo
