From: | "Mark Woodward" <pgsql(at)mohawksoft(dot)com> |
---|---|
To: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: shrinking the postgresql.conf |
Date: | 2005-08-08 20:59:13 |
Message-ID: | 23037.24.91.171.78.1123534753.squirrel@mail.mohawksoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>> Well, if you want PostgreSQL to act a specific way, then you are going
>> to
>> have to set up the defaults somehow, right?
>
> Of course, which is why we could use a global table for most of it.
What if you wish to start the same database cluster with different settings?
>
>>
>> Which is cleaner? Using a configuration file which is going to be there
>> anyway, or trying to rig-up some sort of autostart.sql mechanism to put
>> PostgreSQL into its desired state?
>
> Initdb could easily create this as part of the catalog/cluster.
Assuming you know the tuning parameters at creation time, hint: you don't.
>
>>
>> I periodically get into arguments on hackers because I want *more*
>> options
>> available in postgresql.conf
>
> Then I think we will have to agree to disagree ;).
True.
>
>>
>> My dream is to start postgres like:
>>
>> /opt/postgres/bin/postmaster
>> --config-file=/opt/postgres/bases/tiger.conf
>> or
>> /opt/postgres/bin/postmaster
>> --config-file=/opt/postgres/bases/zipcode.conf
>
> You can do that easily if you have multiple catalogs which is what we do
> when we want that.
I *really* dislike this sort of strategy.
>
>>
>> I also want an include directve that allows production or debugging
>> settings to be easily used.
>>
>
> Such as?
Printing out statement execution, timing, etc. obviously.
From | Date | Subject | |
---|---|---|---|
Next Message | Matt Miller | 2005-08-08 21:01:09 | Re: PL/pgSQL: SELECT INTO EXACT |
Previous Message | Tom Lane | 2005-08-08 20:59:08 | Re: Testing of MVCC |