Re: [HACKERS] pg_dump bug (was Re: [SQL] Slow Inserts Again)

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

Browse pgsql-hackers by date

  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