Bruce Momjian wrote:
Mark Kirkwood wrote:
What if we add an option to initdb to allow the user to specify the name
and location of the postgresql.conf file?
That is certainly a way to approach it, I see the tough bit being the
parsing of postgresql.conf to figure out which parts of the globa
Mark Kirkwood wrote:
> > What if we add an option to initdb to allow the user to specify the name
> > and location of the postgresql.conf file?
>
> That is certainly a way to approach it, I see the tough bit being the
> parsing of postgresql.conf to figure out which parts of the global
> include
Bruce Momjian wrote:
Lamar Owen wrote:
On Monday 27 February 2006 21:09, Bruce Momjian wrote:
One question I have is how this feature would be an improvement over
just pointing pg_ctl at a postgresql.conf configuration file. That
config file has the ability to specify most if not all server
Christopher Browne wrote:
[EMAIL PROTECTED] (Mark Kirkwood) wrote:
Do you need name, value pairs? I was thinking that something like:
# Postgres Cluster Registration
#
# PG_HOME PGDATA PORT
/usr/local/pg7.4.1 /vol01/pggeo 5435
/usr/local/pg7.4.1 /vol01/pgicdmdb 5434
/usr/local/pg7.4
Lamar Owen wrote:
> On Monday 27 February 2006 21:09, Bruce Momjian wrote:
> > One question I have is how this feature would be an improvement over
> > just pointing pg_ctl at a postgresql.conf configuration file. That
> > config file has the ability to specify most if not all server
> > parameter
On Monday 27 February 2006 21:09, Bruce Momjian wrote:
> One question I have is how this feature would be an improvement over
> just pointing pg_ctl at a postgresql.conf configuration file. That
> config file has the ability to specify most if not all server
> parameters.
The big problem is that
On Monday 27 February 2006 19:59, Josh Berkus wrote:
> > My frustration level often kills any desire to contribute to open
> > source. Sometimes, I think that open source is doomed. The various
> > projects I track and use are very frustrating, they remind me of
> > dysfunctional engineering depart
[EMAIL PROTECTED] (Mark Kirkwood) wrote:
> Do you need name, value pairs? I was thinking that something like:
>
> # Postgres Cluster Registration
> #
> # PG_HOME PGDATA PORT
> /usr/local/pg7.4.1 /vol01/pggeo 5435
> /usr/local/pg7.4.1 /vol01/pgicdmdb 5434
> /usr/local/pg7.4.1 /vol03/pg7
Andrew Dunstan wrote:
Mark Kirkwood wrote:
Do you need name, value pairs? I was thinking that something like:
# Postgres Cluster Registration
#
# PG_HOME PGDATA PORT
/usr/local/pg7.4.1 /vol01/pggeo 5435
/usr/local/pg7.4.1 /vol01/pgicdmdb 5434
/usr/local/pg7.4.1 /vol03/pg74
Mark Kirkwood wrote:
Do you need name, value pairs? I was thinking that something like:
# Postgres Cluster Registration
#
# PG_HOME PGDATA PORT
/usr/local/pg7.4.1 /vol01/pggeo 5435
/usr/local/pg7.4.1 /vol01/pgicdmdb 5434
/usr/local/pg7.4.1 /vol03/pg74 5432
Clearly oth
Mark Woodward wrote:
Mark Woodward wrote:
After takin a swig o' Arrakan spice grog, [EMAIL PROTECTED] ("Mark
Woodward") belched out:
I'm not keen on the Windows .ini file style sectioning; that makes it
look like a mix between a shell script and something else. It should
be one or the other
> Mark Woodward wrote:
>>>After takin a swig o' Arrakan spice grog, [EMAIL PROTECTED] ("Mark
>>>Woodward") belched out:
>
>>>I'm not keen on the Windows .ini file style sectioning; that makes it
>>>look like a mix between a shell script and something else. It should
>>>be one or the other. It pro
Mark Woodward wrote:
After takin a swig o' Arrakan spice grog, [EMAIL PROTECTED] ("Mark
Woodward") belched out:
I'm not keen on the Windows .ini file style sectioning; that makes it
look like a mix between a shell script and something else. It should
be one or the other. It probably should b
"Mark Woodward" <[EMAIL PROTECTED]> writes:
> If one can specify a different port than the default on the command line,
> why wouldn't a file designed to describe the server process include it. My
> intention is to include all the options available via environment or
> command lon in the file.
I t
> After takin a swig o' Arrakan spice grog, [EMAIL PROTECTED] ("Mark
> Woodward") belched out:
>>> Mark Woodward wrote:
>> Like I have repeated a number of times, sometimes, there is more than
>> one
>> database cluster on a machine. The proposed pg_clusters.conf, could look
>> like this:
>>
>> pg_
After takin a swig o' Arrakan spice grog, [EMAIL PROTECTED] ("Mark Woodward")
belched out:
>> Mark Woodward wrote:
> Like I have repeated a number of times, sometimes, there is more than one
> database cluster on a machine. The proposed pg_clusters.conf, could look
> like this:
>
> pg_clusters.con
Mark Woodward wrote:
> [TOMLANE]
> DATADIR=/vol03/pg74
> PORT=5433
> POSTMASTER=/usr/local/pg7.4.1/bin/postmaster
Seems better to me to specify PREFIX (the --prefix arg to configure)
instead of POSTMASTER, because then you can search any needed executable
there (pg_config for example). Or maybe
I don't see how this is much better than just pointing to different
configuration file for each postmaster.
---
Mark Woodward wrote:
> > One question I have is how this feature would be an improvement over
> > just pointing
> Mark Woodward wrote:
>> > Mark,
>> >
>> >> Well, I'm sure that one "could" use debian's solution, but that's the
>> >> problem, it isn't PostgreSQL's solution. Shouldn't PostgreSQL provide
>> >> the mechanisms? Will debian support FreeBSD? NetBSD? Is it in the
>> >> PostgreSQL admin manual?
>> >>
> "Mark Woodward" <[EMAIL PROTECTED]> writes:
>> My frustration level often kills any desire to contribute to open
>> source.
>> Sometimes, I think that open source is doomed. The various projects I
>> track and use are very frustrating, they remind me of dysfunctional
>> engineering departments in
Mark Woodward wrote:
> > Mark,
> >
> >> Well, I'm sure that one "could" use debian's solution, but that's the
> >> problem, it isn't PostgreSQL's solution. Shouldn't PostgreSQL provide
> >> the mechanisms? Will debian support FreeBSD? NetBSD? Is it in the
> >> PostgreSQL admin manual?
> >>
> >> We
Mark,
> My frustration level often kills any desire to contribute to open
> source. Sometimes, I think that open source is doomed. The various
> projects I track and use are very frustrating, they remind me of
> dysfunctional engineering departments in huge companies, it is very hard
> to positive
On Mon, Feb 27, 2006 at 03:38:23PM -0500, Mark Woodward wrote:
> Maybe I'm too used to working in engineering groups. I am trying to get
> input for a project. Trying to iron out what the feature set should be and
> the objectives that should be attained. BEFORE I start coding.
Well yes, the probl
"Mark Woodward" <[EMAIL PROTECTED]> writes:
> My frustration level often kills any desire to contribute to open source.
> Sometimes, I think that open source is doomed. The various projects I
> track and use are very frustrating, they remind me of dysfunctional
> engineering departments in huge com
Maybe I'm too used to working in engineering groups. I am trying to get
input for a project. Trying to iron out what the feature set should be and
the objectives that should be attained. BEFORE I start coding.
Well that is always a good idea but:
Just saying "submit a patch" is the antith
> Mark,
>
>> Well, I'm sure that one "could" use debian's solution, but that's the
>> problem, it isn't PostgreSQL's solution. Shouldn't PostgreSQL provide
>> the mechanisms? Will debian support FreeBSD? NetBSD? Is it in the
>> PostgreSQL admin manual?
>>
>> We are talking about a feature, like pg_
> On Mon, Feb 27, 2006 at 11:48:50AM -0500, Mark Woodward wrote:
>> Well, I'm sure that one "could" use debian's solution, but that's the
>> problem, it isn't PostgreSQL's solution. Shouldn't PostgreSQL provide
>> the
>> mechanisms? Will debian support FreeBSD? NetBSD? Is it in the PostgreSQL
>> ad
Mark,
> Well, I'm sure that one "could" use debian's solution, but that's the
> problem, it isn't PostgreSQL's solution. Shouldn't PostgreSQL provide
> the mechanisms? Will debian support FreeBSD? NetBSD? Is it in the
> PostgreSQL admin manual?
>
> We are talking about a feature, like pg_service.c
On Mon, Feb 27, 2006 at 11:48:50AM -0500, Mark Woodward wrote:
> Well, I'm sure that one "could" use debian's solution, but that's the
> problem, it isn't PostgreSQL's solution. Shouldn't PostgreSQL provide the
> mechanisms? Will debian support FreeBSD? NetBSD? Is it in the PostgreSQL
> admin manua
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Mark Woodward
> Sent: 27 February 2006 16:49
> To: Martijn van Oosterhout
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] pg_config, pg_service.conf,
> postgre
> On Mon, Feb 27, 2006 at 09:39:59AM -0500, Mark Woodward wrote:
>> It isn't just "an" environment variable, it is a number of variables and
>> a
>> mechanism. Besides, "profile," from an admin's perspective, is for
>> managing users, not databases.
>
> Sure, you need to control the user, group, pl
On Mon, Feb 27, 2006 at 09:39:59AM -0500, Mark Woodward wrote:
> It isn't just "an" environment variable, it is a number of variables and a
> mechanism. Besides, "profile," from an admin's perspective, is for
> managing users, not databases.
Sure, you need to control the user, group, placement of
> Mark Woodward wrote:
>> > If you require a policy, then YOU are free to choose the policy that
>> > YOU need. You're not forced to accept other peoples' policies that
>> > may conflict with things in your environment.
>>
>> The problem is that there is no mechanism through which one can
>> imple
Mark Woodward wrote:
> > If you require a policy, then YOU are free to choose the policy that
> > YOU need. You're not forced to accept other peoples' policies that
> > may conflict with things in your environment.
>
> The problem is that there is no mechanism through which one can implement
> po
Hi Martijn!
Martijn van Oosterhout [2006-02-23 13:33 +0100]:
> What I mean is that only root can run pg_createcluster (either via
> package installation or directly). At least, that's what my reading of
> the code tells me. Uless you have an pg_adoptcluster somewhere :)
Ah, right, now I know what
On Thu, Feb 23, 2006 at 12:42:52PM +0100, Martin Pitt wrote:
> > The main downside of this system is that some sysadmin pretty much
> > needs to create the clusters for everyone.
>
> What do you mean in particular? The packages install a default cluster
> (e. g. postgresql-8.1 creates a cluster 8.
Hi Mark, hi Martijn!
Martijn van Oosterhout [2006-02-23 12:10 +0100]:
> If you're talking about standards perhaps you should consider how
> Debian does it. All configuration is stored in
>
> /etc/postgresql///
>
> It provides wrapper scripts to run pg_ctl (pg_ctlcluster) on any
> particular clu
On Wed, Feb 22, 2006 at 09:22:14AM -0500, Mark Woodward wrote:
> That's not the issue.
> I find it frustrating sometimes because when I describe one scenario,
> people debate it using other scenarios. Maybe I lack the communications
> skills to convey the problem accurately.
> Now, if there were
Mark Woodward wrote:
Admittedly, given that the binaries are likely to be in the
cluster-owners default PATH, it is not as hard to find them as the data
directory. However, this is all about convenience it would seem, since
(for many *nix platforms) two simple searches will give you most of wh
On Wed, 22 Feb 2006, Mark Woodward wrote:
> > Mark Woodward wrote:
> >
> >> I'm not sure that I agree. At least in my experience, I wouldn't have
> >> more
> >> than one installation of PostgreSQL in a production machine. It is
> >> potentially problematic.
> >>
> >
> > I agree with you for produ
> Mark Woodward wrote:
>
>> I'm not sure that I agree. At least in my experience, I wouldn't have
>> more
>> than one installation of PostgreSQL in a production machine. It is
>> potentially problematic.
>>
>
> I agree with you for production environments, but for development, test,
> support (and
> Quoth [EMAIL PROTECTED] ("Mark Woodward"):
>>> Mark Woodward wrote:
As a guy who administers a lot of systems, sometimes over the span of
years, I can not understate the need for "a" place for the admin to
find
what databases are on the machine and where they are located.
>>>
Peter Eisentraut wrote:
Am Mittwoch, 22. Februar 2006 09:06 schrieb Dave Page:
As an example, pgAdmin uses this info to automatically register any
local installations.
Curiously enough, pgAdmin already has a "Service" field in its connection
dialog, but I guess that isn't the same thing. T
Am Mittwoch, 22. Februar 2006 09:06 schrieb Dave Page:
> As an example, pgAdmin uses this info to automatically register any
> local installations.
Curiously enough, pgAdmin already has a "Service" field in its connection
dialog, but I guess that isn't the same thing. The documentation is unclea
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Mark Kirkwood
> Sent: 22 February 2006 01:53
> To: Mark Woodward
> Cc: Tom Lane; Peter Eisentraut; kleptog@svana.org;
> pgsql-hackers@postgresql.org
> Subject:
Christopher Browne wrote:
In the last exciting episode, [EMAIL PROTECTED] (Mark Kirkwood) wrote:
I agree with you for production environments, but for development,
test, support (and pre-sales) machines there are reasonable
requirements for several.
I still have to ask what *specifically* you
In the last exciting episode, [EMAIL PROTECTED] (Mark Kirkwood) wrote:
> Mark Woodward wrote:
>> I'm not sure that I agree. At least in my experience, I wouldn't
>> have more than one installation of PostgreSQL in a production
>> machine. It is potentially problematic.
>
> I agree with you for prod
Mark Woodward wrote:
I'm not sure that I agree. At least in my experience, I wouldn't have more
than one installation of PostgreSQL in a production machine. It is
potentially problematic.
I agree with you for production environments, but for development, test,
support (and pre-sales) machine
Quoth [EMAIL PROTECTED] ("Mark Woodward"):
>> Mark Woodward wrote:
>>> As a guy who administers a lot of systems, sometimes over the span of
>>> years, I can not understate the need for "a" place for the admin to
>>> find
>>> what databases are on the machine and where they are located.
>>>
>>> Yo
> Mark Woodward wrote:
>
>> As a guy who administers a lot of systems, sometimes over the span of
>> years, I can not understate the need for "a" place for the admin to
>> find
>> what databases are on the machine and where they are located.
>>
>> Your assertion that this file would "only works fo
Mark Woodward wrote:
As a guy who administers a lot of systems, sometimes over the span of
years, I can not understate the need for "a" place for the admin to find
what databases are on the machine and where they are located.
Your assertion that this file would "only works for one root-made
in
Mark Woodward wrote:
> OK, maybe pg_service.conf is not the right place for this, and that
> maybe a valid argument, but the mechanics involved would be a great
> asset to the admin. Perhaps pg_servers.conf?
I can see that being useful, in terms of providing pg_ctl with a list of
instances to sta
Tom Lane wrote:
> > I don't mind a mechanism that pg_ctl can start more than one
> > database cluster.
>
> You mean "pg_ctl start -D pgdatalocation", no?
No, I mean pg_ctl start -D location1 -D location2, better yet controlled
by a configuration file.
--
Peter Eisentraut
http://developer.postgr
> "Mark Woodward" <[EMAIL PROTECTED]> writes:
>>> pg_config --sysconfdir
>
>> Hmm, that doesn't show up with pg_config --help.
>
> It's in 8.1.
>
>> One of my difficulties with PostgreSQL is that there is no
>> "standardized"
>> location for where everything is located, i.e. self documenting. If yo
On Tue, 21 Feb 2006, Mark Woodward wrote:
> > Mark Woodward wrote:
> >> The pg_config program needs to display more information, specifically
> >> where the location of pg_service.conf would reside.
> >
> > pg_config --sysconfdir
>
> Hmm, that doesn't show up with pg_config --help.
>
> [EMAIL PRO
"Mark Woodward" <[EMAIL PROTECTED]> writes:
>> pg_config --sysconfdir
> Hmm, that doesn't show up with pg_config --help.
It's in 8.1.
> One of my difficulties with PostgreSQL is that there is no "standardized"
> location for where everything is located, i.e. self documenting. If you
> know that
On Tue, Feb 21, 2006 at 11:14:58AM -0500, Mark Woodward wrote:
> > pg_config --sysconfdir
>
> Hmm, that doesn't show up with pg_config --help.
What version are you using? If I type pg_config without argument it
appears in the list.
> pg_service.conf may currently be considered a "client side" ut
> Mark Woodward wrote:
>> The pg_config program needs to display more information, specifically
>> where the location of pg_service.conf would reside.
>
> pg_config --sysconfdir
Hmm, that doesn't show up with pg_config --help.
[EMAIL PROTECTED]:~$ pg_config --sysconfdir
pg_config: invalid argume
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Mark Woodward wrote:
>> pg_ctl -S service_name start
> I don't mind a mechanism that pg_ctl can start more than one database
> cluster.
You mean "pg_ctl start -D pgdatalocation", no?
regards, tom lane
--
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Mark Woodward wrote:
>> Also, I know I've been harping on this for years (literally), but
>> since the PosgteSQL programs already have the notion that there is
>> some static directory for which to locate files (pg_service.conf),
>> couldn't we also us
On Tue, Feb 21, 2006 at 09:39:16AM -0500, Mark Woodward wrote:
> The pg_config program needs to display more information, specifically
> where the location of pg_service.conf would reside.
AIUI it's supposed to be in SYSCONFDIR which is displayed by pg_config.
I believe you can place the other con
Mark Woodward wrote:
> The pg_config program needs to display more information, specifically
> where the location of pg_service.conf would reside.
pg_config --sysconfdir
> Also, I know I've been harping on this for years (literally), but
> since the PosgteSQL programs already have the notion that
The pg_config program needs to display more information, specifically
where the location of pg_service.conf would reside.
Also, I know I've been harping on this for years (literally), but since
the PosgteSQL programs already have the notion that there is some static
directory for which to locate f
63 matches
Mail list logo
