From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Ross J(dot) Reedstrom" <reedstrm(at)rice(dot)edu> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] pg_dump bug (was Re: [SQL] Slow Inserts Again) |
Date: | 1999-05-03 22:57:12 |
Message-ID: | 21495.925772232@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Ross J. Reedstrom" <reedstrm(at)rice(dot)edu> writes:
> P.S. shouldn't the non existence of the table handed to pg_dump raise a
> user visible error?
Probably.
> P.P.S. How does one go about setting up a second version of PG to test
> on the same machine, without interference with the production (older)
> version? I've only got the one machine to test on.
No problem, I do that all the time. When running "configure", override
the default install location *and* the default port number. For
example, I build test versions using
--with-pgport=5440 --prefix=/users/postgres/testversion
(You might also want --enable-cassert when working with beta code.)
Build, and make install as per normal --- it will go into the directory
you specified as the prefix. Before doing initdb or starting the test
postmaster, make sure you have environment set up to reference the test
location; the critical stuff is PATH, PGLIB, PGDATA, and USER (initdb
uses USER to decide who'll be superuser).
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Ciaran Dunn | 1999-05-03 23:39:53 | subscribe |
Previous Message | Oleg Bartunov | 1999-05-03 19:35:14 | posmaster failed under high load |