| 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: | Whole Thread | Raw Message | 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 |