Robert Rothe wrote:
> When I type the following at the psql prompt:
>
> select timestamp('now');
Try
select timestamp(now());
Cheers,
Ed Loehr
Maxusers is set to 128. RAM is 256Mg.
Do you think this could be the problem?
> -Original Message-
> From: admin [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, January 11, 2000 12:50 PM
> To: Jeff Eckermann
> Cc: '[EMAIL PROTECTED]'
> Subject: RE: [GENERAL] Memory leak in FreeBSD?
>
What is maxusers set to in your kernel? One prolem I had was that
postgresql was using more filedescriptors that my kernel could handle. If
you'd like to check your current filedescriptor status and your max, try:
pstat -T. If that is your problem, change your maxusers to a suitable
number and rec
FreeBSD port: I don't know enough to know what difference that might make.
Any suggestion you have would be appreciated: thanks.
> -Original Message-
> From: admin [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, January 11, 2000 12:18 PM
> To: Jeff Eckermann
> Cc: '[EMAIL PROTECTED]'
> Subj
hi!
sorry for my stupid question...
is it possible to view logs of postmaster?
i remarked a file named pg_log - what is it for?
Marcin Inkielman
.~.
/V\
// \\
Did you upgrade from source or from the freebsd ports?
> We upgraded to version 6.5.2 recently, running on FreeBSD 3.0. Now we are
> having problems with moderately complex queries failing to complete (backend
> terminating unexpectedly; last one crashed the server). The most likely
> explanati
On Tue, 11 Jan 2000, Jeff Eckermann wrote:
> We upgraded to version 6.5.2 recently, running on FreeBSD 3.0. Now we are
> having problems with moderately complex queries failing to complete (backend
> terminating unexpectedly; last one crashed the server). The most likely
> explanation appears t
We upgraded to version 6.5.2 recently, running on FreeBSD 3.0. Now we are
having problems with moderately complex queries failing to complete (backend
terminating unexpectedly; last one crashed the server). The most likely
explanation appears to be a memory leak. Is there any known problem with
On Tue, 11 Jan 2000, admin wrote:
> > > I'm trying to use an index on a varchar(32) field, but explain keeps
> > > retuning a sequential scan. This is my table and index:
> >
> > I had a similar problem last year when trying to use an index on a
> > char(8) field. Two solutions worked for me:
In the docs directory of the 6.5.3 distribution, I was browsing
through the TODO file. There is a note there:
'Views containing aggregates sometimes fail(Jan)'
In what way do they fail? I need to create several views with
aggregates, and I'm concerned about what the effect will be. I
tried
> > I'm trying to use an index on a varchar(32) field, but explain keeps
> > retuning a sequential scan. This is my table and index:
>
> I had a similar problem last year when trying to use an index on a
> char(8) field. Two solutions worked for me: 1) use "bpchar_ops", and
> 2) leave out the o
> When I type the following at the psql prompt:
>
> select timestamp('now');
>
> ...I always get december 31, 1999.
>
> If I use 'now' as the rvalue to a SET, or within an INSERT, it returns
> the correct date.
>
> Is this a known problem? I'm running 6.5.2-1.
Yikes, confirmed in current sou
On Mon, 10 Jan 2000, admin wrote:
> Following a few suggestions, I have entered 2500 records in the
> manufacturer table. Unfortunately, searching for name in the manufacturer
> table still returned a sequential scan.
>
> I then tried changing the btree index to a hash talbe and went through the
I have changed the name field to a char(32) NOT NULL, and I still get a
sequential scan. I have added the 2500 records and I did "vacuumdb
database" from the command-line. Unfortunately, "vacuum analyze" from the
psql prompt returns a pqReadData() error, loses the connection to the
backend and ret
When I type the following at the psql prompt:
select timestamp('now');
...I always get december 31, 1999.
If I use 'now' as the rvalue to a SET, or within an INSERT, it returns
the correct date.
Is this a known problem? I'm running 6.5.2-1.
Thanks,
Rob
Yes, I did try vacuum analyze, but my search query still uses a sequential
scan.
> > I then tried changing the btree index to a hash talbe and went through the
> > same procedure of vacumming and restarting a psql session. Yet again, the
> > index wasn't being used.
>
> But did you try vacuum an
greets,
does anyone ever look in ftp://ftp.postgresql.org/pub ?
there is a precompiled nt binary in there. has been for a while.
jeff
On Mon, 10 Jan 2000, Ron Chmara wrote:
>
>
> Alexei Zakharov wrote:
> >
> > - Original Message -
> > From: Huynh, Long <[EMAIL PROTECTED]>
> > To: <
I think I've got it thank you every much for your hints.
-Original Message-
From: Ron Chmara [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 11, 2000 12:21 AM
To: Alexei Zakharov
Cc: [EMAIL PROTECTED]; Huynh, Long
Subject: Re: [GENERAL] Intro/Win9X
Alexei Zakharov wrote:
>
> -
hi!
sorry for my stupid question...
is it possible to view logs of postmaster?
i remarked a file named pg_log - what is it for?
Marcin Inkielman
.~.
/V\
// \\
This sort of problem should be fixed in 7.0.
On 2000-01-10, Alain TESIO mentioned:
> Hello,
>
> Maybe you've experienced this problem too : when you have a huge
> script with an error somewhere, it's a pain to find out what
> line produced the error as you can't have the output of psql
> with t
> I then tried changing the btree index to a hash talbe and went through the
> same procedure of vacumming and restarting a psql session. Yet again, the
> index wasn't being used.
But did you try vacuum analyze or just vacuum?
21 matches
Mail list logo
