I've had this happen on 2 seperate servers now.
After reading the docs, I bumped up shared_buffers. On one machine with
2G pyhsical ram, I set the param to use 1G of memory ( 131072 value), on
another machine with 800M of RAM, I set the value to about 500M ( 64000
). ipcs shows the correct a
On Sat, 2002-03-02 at 04:16, Thomas Lockhart wrote:
> > timestamp(timestamp('a timestamp)) no longer works
> > I do this reasonably often in my code by way of being paranoid
> > that I might have a date, or a time, where I for sure _really_
> > want it to be a timestamp...
> > pcnz=# select timest
=?iso-8859-2?Q?Radek_Hrab=E8=E1k?= <[EMAIL PROTECTED]> writes:
> [ sub-SELECT in GROUP BY expression crashes backend ]
This is fixed in 7.2.
regards, tom lane
---(end of broadcast)---
TIP 1: subscribe and unsubscribe comman
Short description: Problem with terminating the backend unexpectedly after
using SELECT statement (see bottom for more). It is not of high importance,
because for that select there is another working solution through using
outer join.
Version of Postgresql:
PostgreSQL 7.1 on i586-pc-linux-gnu, c
Good news.
I looked through the code and after a little debugging found that the STATISTICS
* 300 gives you the sample size of rows used to gather statistics.
With the symbol_data table with 20million tuples and on this column with
about 8000 unique values, i needed a very large sample size.
E
> timestamp(timestamp('a timestamp)) no longer works
> I do this reasonably often in my code by way of being paranoid
> that I might have a date, or a time, where I for sure _really_
> want it to be a timestamp...
> pcnz=# select timestamp('2002-03-01'::timestamp);
> ERROR: parser: parse error at
[EMAIL PROTECTED] writes:
> timestamp(timestamp('a timestamp)) no longer works
timestamp(x) is a type name now. In place of timestamp(foo) use
"timestamp"(foo)
foo::timestamp
CAST(foo AS timestamp)
And yes, this is pointed out in the migration notes...
Reinhard Max <[EMAIL PROTECTED]> writes:
>> The actual rows read from this indexscan seem to be many fewer than
>> the number of rows in the table. What are the ranges of the id
>> values in tables foo and bar? I'm wondering if the merge could have
>> stopped far short of the end of the foo tabl
I also have setlled this problem by installing
libc6-dev_2.2.5-3_i386.deb from debian.org
U> Hello pgsql-bugs,
U> I cannot install postgresql-7.2 on my Debian Linux
U> I have downloaded postgresql-7.2.tar.gz from
U> http://www.ca.postgresql.org/ftpsite/v7.2/postgresql-7.2.tar.gz and
U> t
Hello pgsql-bugs,
I cannot install postgresql-7.2 on my Debian Linux
I have downloaded postgresql-7.2.tar.gz from
http://www.ca.postgresql.org/ftpsite/v7.2/postgresql-7.2.tar.gz and
try to install on Debian linux 2.2 release 5
Here is all info about system, that was get by the command "
Andrew McMillan ([EMAIL PROTECTED]) reports a bug with a severity of 3
The lower the number the more severe it is.
Short Description
timestamp(timestamp('a timestamp)) no longer works
Long Description
In version 7.2 it seems that I can't reduntantly cast value to timestamp if it is
already a t
11 matches
Mail list logo
