This fixes the problem for me.
Thanks,
-rocco
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]
> Sent: Sunday, July 24, 2005 12:37 AM
> To: Andrew Dunstan
> Cc: Patches (PostgreSQL); Rocco Altier
> Subject: Re: [PATCHES] fix integer datetime division rounding
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,
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 read
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 worki
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
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
Index:
Tom Lane wrote:
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
On Tue, Jul 19, 2005 at 10:03:39AM -0400, Tom Lane wrote:
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
Attached is a plpython_error_1.out file that will fix cuckoo.
What is the reason for the difference in the
> Patch includes only changes to backend, I will make pg_dump, ecpg and
> documentation patches once this is completed and accepted by team.
I am ready to apply this patch. Would you make the additional changes
you suggested? Is there any way to see the limits except to query
pg_authid?
--
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
> >
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), asp(A
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),
plat
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
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 s
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.
> reg
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 cl.relna
On Sat, 23 Jul 2005, Bruce Momjian wrote:
> Date: Sat, 23 Jul 2005 11:36:43 -0400 (EDT)
> From: Bruce Momjian
> To: ohp@pyrenet.fr
> Cc: Rocco Altier <[EMAIL PROTECTED]>,
> Michael Glaesemann <[EMAIL PROTECTED]>, pgsql-patches@postgresql.org,
> pgsql-hackers@postgresql.org
> Subject: Re
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
round
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
> Cc: Michael Gl
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 t
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 pr
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
21 matches
Mail list logo
