Re: [GENERAL] Error with tcp/ip networking

2000-08-31 Thread Jules Bean
On Thu, Aug 31, 2000 at 10:15:50AM -0400, Tom Lane wrote: > > netstat did not list them as using a port, > > Actually I think netstat only shows open connections, not processes > listening for connections. Does anyone know a (reasonably portable) > way of seeing which port numbers are being acce

Re: [GENERAL] problems with transactions

2000-08-31 Thread Jules Bean
On Thu, Aug 31, 2000 at 09:43:52AM -0300, Campbell, Scott wrote: > > $sth = $dbh->prepare("begin work"); > $sth->execute(); > [snip error] > > after seeing this I assumed that you just can't use the begin statement > accross the DBI but there has to be a way of opening a transaction (it even

Re: [GENERAL] Error with tcp/ip networking

2000-08-31 Thread Jules Bean
On Thu, Aug 31, 2000 at 07:30:36AM -0500, Travis Bauer wrote: > Well, there were two other copies of postgress running, and at least one > was tying up port 5432, but . . . > > I couldn't see them with 'ps' or 'ps -a', netstat did not list them as > using a port, but it did list something as havi

Re: [GENERAL] Large selects handled inefficiently?

2000-08-31 Thread Jules Bean
On Thu, Aug 31, 2000 at 09:58:34AM +0100, Jules Bean wrote: > On Thu, Aug 31, 2000 at 03:28:14PM +1100, Chris wrote: > > > but it is true that this is a flaw in postgres. It has been > > discussed on hackers from time to time about implementing a "streaming" > &

Re: [GENERAL] Error with tcp/ip networking

2000-08-31 Thread Jules Bean
On Thu, Aug 31, 2000 at 01:33:35AM -0400, Tom Lane wrote: > "Travis Bauer" <[EMAIL PROTECTED]> writes: > > I'm getting: > > FATAL: StreamServerPort: bind() failed: Address already in use > > Is another postmaster already running on that port? > > If not, wait a few seconds and retr

Re: [GENERAL] Large selects handled inefficiently?

2000-08-31 Thread Jules Bean
On Thu, Aug 31, 2000 at 03:28:14PM +1100, Chris wrote: > Jules Bean wrote: > > > > On Thu, Aug 31, 2000 at 12:22:36AM +1000, Andrew Snow wrote: > > > > > > > I believe I can work around this problem using cursors (although I > > > > don't know

Re: [GENERAL] Large selects handled inefficiently?

2000-08-30 Thread Jules Bean
On Thu, Aug 31, 2000 at 12:22:36AM +1000, Andrew Snow wrote: > > > I believe I can work around this problem using cursors (although I > > don't know how well DBD::Pg copes with cursors). However, that > > doesn't seem right -- cursors should be needed to fetch a large query > > without having it

[GENERAL] Large selects handled inefficiently?

2000-08-30 Thread Jules Bean
Hiya, I am running a very large SELECT - it selects every row from a ~10 000 000 row table. I'm running this in Perl using DBD:Pg, with the general sequence: $sth = $dbh->prepare("SELECT $fields FROM $from") || return 0; $fh = new FileHandle(">$file") || die "Can't open $file : $!"; $sth->execut

Re: [GENERAL] using INTERSECT and UNION in IN clause

2000-08-22 Thread Jules Bean
On Tue, Aug 22, 2000 at 01:50:26PM +0400, Alex Guryanow wrote: > Hi, > > postgresql 7.0.2. Why by executing the following query > > select * from magazine > where id in ( > select mag_id from dict where word = 'akademie' intersect > select mag_id from dict where word = 'der' intersec

Re: [GENERAL] Re: [HACKERS] 8Ko limitation

2000-07-20 Thread Jules Bean
that's what it has done on my last project). FWIW, the 2Gig limit doesn't exist on 64bit linux, AFAIK (at least, not with a 64-bit happy libc; I can't remember if the patches made it into the version we use in Debian). Jules -- Jules Bean |Any suf