Hi Dave,
Thanks for the info, this explains a lot.
Yes, I am upgrading from the 32bit version to the 64bit one.
We have pretty large databases (some over 1 trillion of rows, and some
containing large documents in blobs.) Giving a bit more memory than 4GB
limit to Postgres was what we were lo
"Henry" writes:
> Before I run this again, what's the best way to proceed to get a core dump
> so I can run a gdb backtrace to provide more info? Simply 'ulimit -c
> 5242880' as user postgres and restart PG?
I'd use "ulimit -c unlimited", myself, rather than making arbitrary
assumptions about ho
On Sat, Oct 30, 2010 at 11:23 AM, Tom Lane wrote:
>
> Anybody want to try Oracle, DB2, etc?
Oracle seems to behave like us:
SQL> select * from (select 1 as x from dual) where 1=1and x=1;
X
--
1
--
greg
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.or
The following bug has been logged online:
Bug reference: 5736
Logged by: Henry
Email address: he...@cityweb.co.za
PostgreSQL version: 9.0.1
Operating system: Linux
Description:9.0.1 segmentation fault (sig11) during long-lived
update
Details:
Hi,
I'm using PostgreS
MS SQL server 2008 has no problem with this:
select * from client where CLIENT_ID = 12AND SNAME='Smith'
Returns the expected row.
PostgreSQL 9.0 has no problem with it either, again throwing no error
and returning the expected result.
Regards,
Gary.
On 30/10/2010 7:23 PM, Tom Lane wrote:
G
Greg Stark writes:
> On Thu, Oct 28, 2010 at 5:20 PM, Tom Lane wrote:
>> I experimented a bit with mysql's behavior, and it seems that (at least
>> in 5.1.51) what they do is treat "1and" or "2or" as if it were an
>> identifier. They're definitely not throwing an error, at least not on
> I gues
On Thu, Oct 28, 2010 at 5:20 PM, Tom Lane wrote:
> I experimented a bit with mysql's behavior, and it seems that (at least
> in 5.1.51) what they do is treat "1and" or "2or" as if it were an
> identifier. They're definitely not throwing an error, at least not on
>
I guess the eleant question is
On Sat, Oct 30, 2010 at 3:29 PM, Arturas Mazeika wrote:
>
> -
> Checking old data directory (I:\PostgreSQL\8.3\data) ok
> Checking old bin directory (C:\Program Files (x86)\PostgreSQL\8.3\bin)ok
> Checking new data directory (I:\PostgreSQL\9.0) ok
> C
The following bug has been logged online:
Bug reference: 5735
Logged by: Arturas Mazeika
Email address: maze...@gmail.com
PostgreSQL version: 9.0
Operating system: Windows Server 2003
Description:pg_upgrade thinks that it did not start the old server
Details:
1. I a
The following bug has been logged online:
Bug reference: 5733
Logged by: Marcus Wirsing
Email address: m...@hesotech.de
PostgreSQL version: 9.0.1
Operating system: Windows XP 32
Description:Strange planer behaviour with inherited tables
Details:
when I execute the f
"Mark Stosberg" writes:
> The "autovacuum_enabled" storage parameter claims to be a boolean type:
> http://www.postgresql.org/docs/9.0/static/sql-createtable.html#SQL-CREATETAB
> LE-STORAGE-PARAMETERS
> ... but it fails to behave a normal boolean.
The parsing is the same as every other boolean pa
The following bug has been logged online:
Bug reference: 5734
Logged by: Mark Stosberg
Email address: m...@summersault.com
PostgreSQL version: 9.0.1
Operating system: FreeBSD
Description:autovacuum_enabled input should be validated,
standardized.
Details:
The "autov
12 matches
Mail list logo
