Andrew pointed out that the current fix didn't handle dates that were
near daylight savings time boudaries. This handles it properly, e.g.
test= select '2005-04-03 04:00:00'::timestamp at time zone
'America/Los_Angeles';
timezone
Rocco Altier wrote:
This patch fixes the interval regression on my AIX box (kookaburra) by
only doing integer math on the interval, instead of float/double math.
I think this is the correct way to handle this, since it's an integer
data type.
I don't know if it will fix Olivier's problem,
This still does not fix the problem.
I had done my patch to try to mimic the way 8.0 had handled the math
with the remainders, but to carry it over another bucket (day).
The problem that I see is that we are taking day_remainder and
multiplying by USECS_PER_DAY. Which is a double * int64, thus
I just checked latest CVS (5 mn ago) the problem is still the same,
BTW, this is on Unixware 714 and no --enable-integer-datetime
Regards
On Sat, 23 Jul 2005, Rocco Altier wrote:
Date: Sat, 23 Jul 2005 11:15:44 -0400
From: Rocco Altier [EMAIL PROTECTED]
To: Bruce Momjian
ohp@pyrenet.fr wrote:
I just checked latest CVS (5 mn ago) the problem is still the same,
BTW, this is on Unixware 714 and no --enable-integer-datetime
Do you have the latest patch included int that version of CVS?
Anonymous CVS has a delay, and what was the problem you were seeing, the
On Sat, 23 Jul 2005, Bruce Momjian wrote:
Date: Sat, 23 Jul 2005 11:36:43 -0400 (EDT)
From: Bruce Momjian pgman@candle.pha.pa.us
To: ohp@pyrenet.fr
Cc: Rocco Altier [EMAIL PROTECTED],
Michael Glaesemann [EMAIL PROTECTED], pgsql-patches@postgresql.org,
pgsql-hackers@postgresql.org
I think the patch is ok now, intervall is not failing anymore as of
18:50 CET.
However stats fails.
regression.diffs:
*** ./expected/stats.outSat Jul 23 17:18:20 2005
--- ./results/stats.out Sat Jul 23 18:55:17 2005
***
*** 53,59
WHERE st.relname='tenk2' AND
Yes, we have seen those stat tests fail randomly. We are working on a
solution.
---
ohp@pyrenet.fr wrote:
I think the patch is ok now, intervall is not failing anymore as of
18:50 CET.
However stats fails.
I have modified and attached your patch for your review. I didn't see
any value to adding new fsync_method values because, to me, O_DIRECT is
basically just like O_SYNC except it doesn't keep a copy of the buffer
in the kernel cache. If you are doing fsync(), I don't see how O_DIRECT
makes any
Would you please try the attached patch and let me know if it fixes the
problem? I avoided accumulating into a float8.
---
Rocco Altier wrote:
This still does not fix the problem.
I had done my patch to try to mimic
That still does not fix it for me.
This patch is still using a computed float value (month_remainder and
day_remainder), which is cauing the rounding errors.
There are now 6 machines on the build farm that are failing from the
rounding:
Wallaroo (OSX/G4), asp(AIX/powerpc), viper(FC3/x86_64),
Rocco Altier wrote:
That still does not fix it for me.
This patch is still using a computed float value (month_remainder and
day_remainder), which is cauing the rounding errors.
There are now 6 machines on the build farm that are failing from the
rounding:
Wallaroo (OSX/G4),
Bruce Momjian wrote:
Rocco Altier wrote:
That still does not fix it for me.
This patch is still using a computed float value (month_remainder and
day_remainder), which is cauing the rounding errors.
There are now 6 machines on the build farm that are failing from the
rounding:
The attached patch seems to fix the rounding error that is causing
regression failures on machines with integer datetimes. (Source of error
discovered by [EMAIL PROTECTED]).ISTM this code needs to be given some
careful analysis - I know it makes my head spin reading it.
cheers
andrew
Michael Fuhr [EMAIL PROTECTED] writes:
Tom Lane wrote:
Hmm ... if it's *not* a version thing then I really do want to know
what's causing it. Anyone have an idea why this machine is saying
'\u80' where everyone else's python says u'\x80' ?
The regression tests that are failing are from the
On Sat, Jul 23, 2005 at 07:58:21PM -0400, Andrew Dunstan wrote:
Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
I don't think it's a version issue; cuckoo is at 2.4, platypus used to
be at 2.3 but I upgraded it to 2.4 to see if that was the issue, but
platypus kept working.
Hmm ...
Andrew Dunstan wrote:
The attached patch seems to fix the rounding error that is causing
regression failures on machines with integer datetimes. (Source of error
discovered by [EMAIL PROTECTED]).ISTM this code needs to be given some
careful analysis - I know it makes my head spin reading
Attached patch fixes the SHLIB_LINK to add pgport now that pg_usleep is
added.
This is needed for AIX to resolve symbols at compile time.
This is also to be used in conjuction with the other patch I have
pending for Makefile.aix to SHLIB_LINK instead of LIBS to compile shared
objects.
Thanks,
18 matches
Mail list logo
