"Marco Vieira" writes:
> If I query select round(sin(2.0*pi()*0.51)) I get "-0" as return but zero is
> unsigned.
In IEEE-standard float arithmetic, that isn't true --- zero and minus
zero are distinguishable values. This is not a bug but just the way
your platform chooses to define the result o
The following bug has been logged online:
Bug reference: 4653
Logged by: Marco Vieira
Email address: maovie...@gmail.com
PostgreSQL version: 8.3.5
Operating system: x86_64-pc-linux-gnu (ubuntu 4.3.2-1ubuntu11 )
Description:zero with negative sign returned on round(sin
Scott Carey writes:
> Child tables of the table in question:
> select count (*) from pg_tables where tablename like pp_logs%';
> count
> ---
> 6062
This is not a bug. Please note the caveat in the fine manual, at the
bottom of
http://www.postgresql.org/docs/8.3/static/ddl-partitioning.htm
>>> "Nitin" wrote:
> Is the server running on host "PostgreSQL" and
> accepting TCP/IP connections on port 5432?
This is very unlikely to be a bug, so a better list would have been
general or admin.
You probably haven't configured connections properly for your intended
use. Start with this p
The following bug has been logged online:
Bug reference: 4652
Logged by: carl baptista
Email address: c...@multimax.co.za
PostgreSQL version: 8.3
Operating system: win xp
Description:.net upate
Details:
hi,
I have included the Npgsql dll in my c# webservice.
I am
The following bug has been logged online:
Bug reference: 4651
Logged by: Nitin
Email address: nitin.ye...@aviontechnology.net
PostgreSQL version: PostgreSQL 8.3.
Operating system: windows Xp
Description:Postgresql connection error with PHP 5.
Details:
hello ,
I got
* Tom Lane [Thu, 12 Feb 2009 19:10:34 -0500]:
[ shrug... ] The "implementation artifact" is that you didn't get a
deadlock *earlier*.
I agree that such behavior is more plain rather than current.
You can't expect to update referenced rows and
referencing rows in the same transaction and not
Linux, CentOS 5.2, Postgres 8.3.4, 8.3.5. System tables and user tables listed
below have been VACUUM'd, ANALYZE'd and REINDEX'd.
Summary:
Simple update / delete queries that hit a parent table façade of a large
partitioned database are taking 15 to 20 seconds to plan (and a couple ms to
exec
