On Fri, Feb 03, 2006 at 08:05:48AM -0500, Mark Woodward wrote:
Like I said, in this thread of posts, yes there are ways of doing this,
and I've been doing it for years. It is just one of the rough eges that I
think could be smoother.
(in php)
pg_connect(dbname=geo host=dbserver);
Could
Josh Berkus wrote:
Mark,
Even though they run on the same machine, run the same version of the
software, and are used by the same applications, they have NO
interoperability. For now, lets just accept that they need to be on
separate physical clusters because some need to be able to started
Mark Woodward schrieb:
...
Unless you can tell me how to insert live data and indexes to a cluster
without having to reload the data and recreate the indexes, then I
hardly
think I am misinformed. The ad hominem attack wasn't nessisary.
I see you had a usecase for something like pg_diff
Mark Woodward [EMAIL PROTECTED] writes:
The point is, that I have been working with this sort of use case for a
number of years, and being able to represent multiple physical databases
as one logical db server would make life easier. It was a brainstorm I had
while I was setting this sort of
On Fri, Feb 03, 2006 at 08:05:48AM -0500, Mark Woodward wrote:
Using the /etc/hosts file or DNS to maintain host locations for is a
fairly common and well known practice, but there is no such mechanism for
ports. The problem now becomes a code issue, not a system administration
issue.
Mark Woodward [EMAIL PROTECTED] writes:
The point is, that I have been working with this sort of use case for
a
number of years, and being able to represent multiple physical databases
as one logical db server would make life easier. It was a brainstorm I
had
while I was setting this sort
Mark Woodward wrote:
Oh come on, misinformed? is that really called for?
Claiming that all databases share the same system tables is misinformed,
with no judgement passed.
The street database is typically generated and QAed in the lab. It is
then uploaded to the server. It has many millions
Mark Woodward [EMAIL PROTECTED] writes:
It is similar to a proxy, yes, but that is just part of it. The setup and
running of these systems should all be managed.
All that requires is some scripts that wrap pg_ctl and bring the right
instances up and down, perhaps with a web interface on top of
[EMAIL PROTECTED] (Mark Woodward) writes:
The port aspect is troubling, it isn't really self
documenting. The application isn't psql, the applications are custom
code written in PHP and C/C++.
Nonsense. See /etc/services
Using the /etc/hosts file or DNS to maintain host locations for is
a
On Feb 3, 2006, at 6:47 AM, Chris Campbell wrote:
On Feb 3, 2006, at 08:05, Mark Woodward wrote:
Using the /etc/hosts file or DNS to maintain host locations for
is a
fairly common and well known practice, but there is no such
mechanism for
ports. The problem now becomes a code issue, not
On Feb 3, 2006, at 12:43, Rick Gigger wrote:
If he had multiple ips couldn't he just make them all listen only
on one specific ip (instead of '*') and just use the default port?
Yeah, but the main idea here is that you could use ipfw to forward
connections *to other hosts* if you wanted
Mark, all:
So your databases would listen on 5433, 5434, etc and the proxy would
listen on 5432 and route everything properly. If a particular cluster
is not up, the proxy could just error out the connection.
Hmm, that'd be fun to write if I ever find the time...
It is similar to a
On Fri, 3 Feb 2006, Josh Berkus wrote:
The feature you proposed is a way to make your idiosyncratic setup easier
to manage, but doesn't apply to anyone else's problems on this list, so
you're going to have a hard time drumming up enthusiasm.
I am somewhat reluctant to interject into this
Jeremy,
The immediate use I thought of was being able to have what appeared to
be multiple databases on the same server with different locale settings,
which cannot be changed post-initdb.
Again, this is patching the symtoms instead of going after the cause. The
real issue you're trying to
On Feb 3, 2006, at 12:43, Rick Gigger wrote:
If he had multiple ips couldn't he just make them all listen only
on one specific ip (instead of '*') and just use the default port?
Yeah, but the main idea here is that you could use ipfw to forward
connections *to other hosts* if you wanted to.
On Feb 3, 2006, at 6:47 AM, Chris Campbell wrote:
On Feb 3, 2006, at 08:05, Mark Woodward wrote:
Using the /etc/hosts file or DNS to maintain host locations for
is a
fairly common and well known practice, but there is no such
mechanism for
ports. The problem now becomes a code issue, not
Mark Woodward wrote:
On Feb 3, 2006, at 6:47 AM, Chris Campbell wrote:
On Feb 3, 2006, at 08:05, Mark Woodward wrote:
Using the /etc/hosts file or DNS to maintain host locations for
is a
fairly common and well known practice, but there is no such
mechanism for
ports. The
I am working on an issue that I deal with a lot, there is of course a
standard answer, but maybe it is something to think about for PostgreSQL
9.0 or something. I think I finally understand what I have been fighting
for a number of years. When I have been grousing about postgresql
configuration,
On Thu, 2006-02-02 at 10:23 -0500, Mark Woodward wrote:
If one db is REALLY REALLY huge and doesn't change, and a few
others are small and change often, pg_dumpall will spend most of its time
dumping the unchanging data.
My usual backup strategy does pg_dumpall -g to get the (tiny) global
Mark Woodward [EMAIL PROTECTED] writes:
One of the problems with the current PostgreSQL design is that all the
databases operated by one postmaster server process are interlinked at
some core level. They all share the same system tables. If one database
becomes corrupt because of disk or
Mark Woodward [EMAIL PROTECTED] writes:
One of the problems with the current PostgreSQL design is that all the
databases operated by one postmaster server process are interlinked at
some core level. They all share the same system tables. If one database
becomes corrupt because of disk or
Mark Woodward wrote:
Mark Woodward [EMAIL PROTECTED] writes:
One of the problems with the current PostgreSQL design is that all the
databases operated by one postmaster server process are interlinked at
some core level. They all share the same system tables. If one database
becomes corrupt
Mark Woodward wrote:
Seriously? No use at all? You don't see any purpose in controlling and
managing multiple postgresql postmaster processes from one central point?
I'd rather spend effort in fixing the problems that arise from big
databases; for example Hannu's patch for concurrent vacuum
On Thu, 2 Feb 2006, Mark Woodward wrote:
Now, the answer, obviously, is to create multiple postgresql database
clusters and run postmaster for each logical group of databases, right?
That really is a fine idea, but
Say, in pgsql, I do this: \c newdb It will only find the database that I
On Thu, 2 Feb 2006, Mark Woodward wrote:
Now, the answer, obviously, is to create multiple postgresql database
clusters and run postmaster for each logical group of databases, right?
That really is a fine idea, but
Say, in pgsql, I do this: \c newdb It will only find the database that
On Thu, Feb 02, 2006 at 02:05:03PM -0500, Mark Woodward wrote:
My issue is this, (and this is NOT a slam on PostgreSQL), I have a number
of physical databases on one machine on ports 5432, 5433, 5434. All
running the same version and in fact, installation of PostgreSQL.
One way of acheiving
Mark,
Even though they run on the same machine, run the same version of the
software, and are used by the same applications, they have NO
interoperability. For now, lets just accept that they need to be on
separate physical clusters because some need to be able to started and
stopped while
Mark Woodward wrote:
My issue is this, (and this is NOT a slam on PostgreSQL), I have a number
of physical databases on one machine on ports 5432, 5433, 5434. All
running the same version and in fact, installation of PostgreSQL.
Even though they run on the same machine, run the same version of
Mark Woodward wrote:
From an administration perspective, a single point of admin would
seem like a logical and valuable objective, no?
I don't understand why you are going out of your way to separate your
databases (for misinformed reasons, it appears) and then want to design
a way to
Mark Woodward wrote:
From an administration perspective, a single point of admin would
seem like a logical and valuable objective, no?
I don't understand why you are going out of your way to separate your
databases (for misinformed reasons, it appears) and then want to design
a way to
Mark Woodward schrieb:
...
Unless you can tell me how to insert live data and indexes to a cluster
without having to reload the data and recreate the indexes, then I hardly
think I am misinformed. The ad hominem attack wasn't nessisary.
I see you had a usecase for something like pg_diff and
31 matches
Mail list logo
