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 an
Chris Campbell schrieb:
...
> That was a very simplistic example and didn't illustrate my point -- I
> apologize. I was trying to think of something succinct and illustrative
> for a quick mailing list post but came up short.
>
> Maybe a better example would be a situation where you want to do
John wrote:
> I am writing some plugin for pq. After running ./configure and make,
> shall I just go to /src/bin/psql to execute my executable psql -U
> (usrname) dbname? It seems that my updates in the file parse_expr.c
> is not reflect in this executable?
Evidently you're not (only) writing a pl
"Flavio Caiuby" <[EMAIL PROTECTED]> writes:
> The error is " Column "datpath"does not exist " .
You need a newer version of pgadmin --- pg_database.datpath went away
in PG 8.0, but older versions of pgadmin don't know about that.
regards, tom lane
On Feb 2, 2006, at 23:33, Greg Stark wrote:
The "right" way to go about this in the original abstract set-
theoretic
mindset of SQL is to code the view to retrieve all the rows and
then apply
further WHERE clause restrictions to the results of the view.
So for example this:
CREATE VIEW
Chris Campbell <[EMAIL PROTECTED]> writes:
> What do you think? Is this an interesting feature? Is this the right way to
> go
> about it, or should I try to get the planner to see through SQL function
> boundaries
The "right" way to go about this in the original abstract set-theoretic
mindset
Greetings,
I am writing some plugin for pq. After running ./configure and make, shall I
just go to /src/bin/psql to execute my executable psql -U (usrname) dbname?
It seems that my updates in the file parse_expr.c is not reflect in this
executable? For example, I changed one line from
if (
> 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
* Stephen Frost ([EMAIL PROTECTED]) wrote:
> and it's somewhat frustrating since the end of that thread is a
> reasonably small patch which fixes the problem:
>
> http://archives.postgresql.org/pgsql-interfaces/2002-05/msg00083.php
Erp, not quite sure how I managed that, the end of the thre
Greetings,
I've just run smack-dab into the bug described here:
http://archives.postgresql.org/pgsql-interfaces/2002-05/msg00083.php
and it's somewhat frustrating since the end of that thread is a
reasonably small patch which fixes the problem:
http://archives.postgresql.org/pgsql-int
I believe pgAdmin only supports PostgreSQL 7.3 and above.
Chris
Flavio Caiuby wrote:
Dear hackers
I have downloaded and instaled pgadim2 (and pgadmin3 corrected for my
Windows98 -second edition) .When I
try to conect my web server, where I have an AVL program
to nurse and inspect an err
Kevin Grittner wrote:
> >> to generalize it. As far as I can tell from some testing today,
> >> everything works fine issuing statements through a connection, but
> psql
> >> isn't settled down.
> >
> > Sounds like you made great progress!
>
> Thanks. It was actually pretty easy once I took the
On Fri, Jan 27, 2006 at 01:12:35PM -0500, Greg Stark wrote:
>
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>
> > David I don't get this... what are you copying from/to that would
> > wouldn't just script? If you throw into a script you can change
> > the delimiter on the fly using translation.
I've written some complicated queries that I'd like to save inside
the server and then call from my clients using a short name. For the
queries that require no external information, views are perfect. For
queries that *do* require external information (like a search date
range), I've used f
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 centra
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
Dear hackers
I have downloaded and instaled
pgadim2 (and pgadmin3 corrected for my Windows98 -second
edition) .When I
try to conect my web server, where
I have an AVL program
to nurse and inspect an error message comes and I cannot proceed with the
inspection.
The error is " Column "d
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 whi
>>> On Wed, Feb 1, 2006 at 10:50 am, in message
<[EMAIL PROTECTED]>, Bruce Momjian
wrote:
> Kevin Grittner wrote:
>> We found a bug in the code from my first patch. Since it was a low
>> frequency, non- destructive type of problem for us, I was able to
take my
>> time and look over the task a li
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
> 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 da
Rocco Altier wrote:
> I wanted to chime in that I also see this speedup from using XLC 6.0
> (IBM's cc), even in 32bit mode. I have tested on AIX 5.2 and 5.1.
>
> I think this would be good to include in the regular release.
>
> Not sure how many people are running older versions of AIX that w
ITAGAKI Takahiro wrote:
> Bruce Momjian wrote:
>
> > > - Is fillfactor useful for hash and gist indexes?
> > > I think hash does not need it, but gist might need it.
> >
> > Not sure. We don't know what type of index a GIST will be so we have no
> > way of knowing. I am thinking we can imp
I wanted to chime in that I also see this speedup from using XLC 6.0
(IBM's cc), even in 32bit mode. I have tested on AIX 5.2 and 5.1.
I think this would be good to include in the regular release.
Not sure how many people are running older versions of AIX that would
want a new version of postg
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 t
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 a
Hi all,
After spending some time (~2 days to fully(?) understand the process)
setting up a standby machine using WAL shipping and experimentations to
be fairly sure it is working reliably, I started thinking of how I would
like it to be done.
My dream-process of setting up a standby would be:
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" <[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
"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 o
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
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, th
Hannu Krosing wrote:
Ühel kenal päeval, K, 2006-02-01 kell 18:08, kirjutas Tom Lane:
Hannu Krosing <[EMAIL PROTECTED]> writes:
Does ALTER TABLE SET TABLESPACE lock the table
It had better ... see nearby discussion about relaxing locking for
TRUNCATE.
Is it some recent
Ühel kenal päeval, K, 2006-02-01 kell 18:08, kirjutas Tom Lane:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > Does ALTER TABLE SET TABLESPACE lock the table
>
> It had better ... see nearby discussion about relaxing locking for
> TRUNCATE.
Is it some recent disussion ?
> Exactly the same pro
Bruce Momjian wrote:
> > - Is fillfactor useful for hash and gist indexes?
> > I think hash does not need it, but gist might need it.
>
> Not sure. We don't know what type of index a GIST will be so we have no
> way of knowing. I am thinking we can implement just btree now and the
> GIST f
35 matches
Mail list logo