Tom Lane wrote:
> Bruce Momjian writes:
> >> On 10/30/2010 7:33 PM, Dave Page wrote:
> >>> upgrade from a 32bit 8.3 server to a 64 bit 9.0 server, which isn't
> >>> going to work without a dump/restore. With pg_upgrade, the two builds
> >>> need to be from the same platform, same word size, and ha
On 11/10/2010 05:32 AM, Tom Lane wrote:
Bruce Momjian writes:
On 10/30/2010 7:33 PM, Dave Page wrote:
upgrade from a 32bit 8.3 server to a 64 bit 9.0 server, which isn't
going to work without a dump/restore. With pg_upgrade, the two builds
need to be from the same platform, same wo
The following bug has been logged online:
Bug reference: 5745
Logged by: Jin
Email address: jind...@gmail.com
PostgreSQL version: 8.4.5
Operating system: windows xp pro sp3
Description:geometry bug?
Details:
The distance of the horizontal lseg and the point on that
I use the postgresql in default configuration and use inheritance way to create
table.
My postgresql version is:
SELECT version();
version
--
The following bug has been logged online:
Bug reference: 5746
Logged by: Jeff Mace
Email address: jeff.m...@continuent.com
PostgreSQL version: 9.0.1
Operating system: CentOS
Description:/etc/init.d/postgresql-9.0 status returns the wrong
value
Details:
The following
On 10/11/10 10:08, Jin wrote:
The following bug has been logged online:
Bug reference: 5745
Logged by: Jin
Email address: jind...@gmail.com
PostgreSQL version: 8.4.5
Operating system: windows xp pro sp3
Description:geometry bug?
Details:
The distance of the horizont
The following bug has been logged online:
Bug reference: 5747
Logged by: Kurt Stam
Email address: ks...@apache.org
PostgreSQL version: 8.3
Operating system: OSX
Description:TimeStamps too far into the future are invalid
Details:
https://issues.apache.org/jira/browse
Mike Fowler writes:
> On 10/11/10 10:08, Jin wrote:
>> The distance of the horizontal lseg and the point on that is inaccurate.
> From my digging it appears that this is returning the distance between
> the first point in the line and the individual point.
I didn't look into the code yet, but t
"Kurt Stam" writes:
> https://issues.apache.org/jira/browse/JUDDI-374
There is no evidence whatsoever on that page to demonstrate that there's
any such postgresql bug. What's more, simple testing suggests that PG
is perfectly happy with timestamps of 2100 or even further out. If
you'd like us t
I wrote:
> So I'm thinking somebody fat-fingered the corner case
> where the perpendicular would have infinite slope, and it is falling
> through to the "take the nearer endpoint" case when it shouldn't.
Actually it's more basic than that: the line_construct_pm() function
is just completely bogus
t...@sss.pgh.pa.us (Tom Lane) writes:
> https://issues.apache.org/jira/browse/JUDDI-374
There's an issue that JDBC doesn't cope very well with 'Infinity'
values, which is more or less the opposite of what's reported here. I
have been tending to put "don't allow +/-Infinity" constraints onto
time
On Tue, 2010-10-26 at 10:48 +0300, Heikki Linnakangas wrote:
> > The reason I didn't use ReadRecord is because it sets a global variable
> > to point to the next location in the log, so that subsequent calls can
> > just pass NULL for the location.
>
> True. XLogPageRead is new in 9.0, however. We
On Wed, 2010-11-10 at 15:13 +, Jeff Mace wrote:
> The following code change is required in the script to check for the
> proper file.
>
> status -p /var/run/postmaster-9.0.${PGPORT}pid
>
> should be
>
> status -p /var/run/postmaster-9.0.${PGPORT}.pid
>
> A '.' is needed after ${PGPORT}.
T
13 matches
Mail list logo
