I ran Tom's second script for two hours on an AMD Duron on Linux 2.4.18.
No problems.
Gavin
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
On Fri, Nov 28, 2003 at 08:22:30PM -0500, Tom Lane wrote:
One variable I didn't think to ask about is whether you are running
NTP. In my experience an ntp daemon that has achieved lock will never
step the clock back by even 1 usec (it's supposed to use much more
subtle methods than that to
I said:
I'm wondering if there's an actual bug in gettimeofday() in this
platform, such that once in a while it returns a value that's off
a minute or so ...
Whoa. Try the following test program. Then send it in to your friendly
local BSD hackers
uname -a
FreeBSD pgsql74.hub.org
On November 28, 2003 12:33 pm, Tom Lane wrote:
I said:
I'm wondering if there's an actual bug in gettimeofday() in this
platform, such that once in a while it returns a value that's off
a minute or so ...
Whoa. Try the following test program. Then send it in to your friendly
local BSD
Darcy Buskermolen [EMAIL PROTECTED] writes:
On November 28, 2003 12:33 pm, Tom Lane wrote:
Whoa. Try the following test program. Then send it in to your friendly
local BSD hackers
I've been running this code on a pair of FreeBSD (i386) boxen, for some time
now, one of which is a
I said:
The failure is definitely quite repeatable on pgsql74.hub.org. I don't
see it on svr1.postgresql.org, though, which seems to be running almost
the same kernel.
After looking more closely, I take that back: svr1 is failing too,
though not as often:
uname -a
FreeBSD
On November 28, 2003 12:33 pm, Tom Lane wrote:
I said:
I'm wondering if there's an actual bug in gettimeofday() in this
platform, such that once in a while it returns a value that's off
a minute or so ...
Whoa. Try the following test program. Then send it in to your friendly
local BSD
On Fri, 28 Nov 2003, Tom Lane wrote:
Darcy Buskermolen [EMAIL PROTECTED] writes:
On November 28, 2003 12:33 pm, Tom Lane wrote:
Whoa. Try the following test program. Then send it in to your friendly
local BSD hackers
I've been running this code on a pair of FreeBSD (i386) boxen,
On November 28, 2003 04:19 pm, Tom Lane wrote:
I said:
The failure is definitely quite repeatable on pgsql74.hub.org. I don't
see it on svr1.postgresql.org, though, which seems to be running almost
the same kernel.
After looking more closely, I take that back: svr1 is failing too,
Nigel J. Andrews [EMAIL PROTECTED] writes:
On an Intel Linux 2.4.18 I get them quite often, 25 in 1'45, but they
are all just a microsecond.
What do you mean by just a microsecond?
Attached is a tightened-up test program that will only complain if the
value of gettimeofday goes backward (at
On Fri, 28 Nov 2003, Tom Lane wrote:
Nigel J. Andrews [EMAIL PROTECTED] writes:
On an Intel Linux 2.4.18 I get them quite often, 25 in 1'45, but they
are all just a microsecond.
What do you mean by just a microsecond?
I mean it's always a out of order tv_usec... line and the difference
Darcy Buskermolen [EMAIL PROTECTED] writes:
After 30+ minutes I'm now starting to see the same problems on my 5.2 testbed
as well. I'm going to fire this test up on my FreeBSD 3.x and 2.x boxen and
see if' it's there too. I can confirm that this not a SMP issue as that it's
happeing on both
Nigel J. Andrews [EMAIL PROTECTED] writes:
On Fri, 28 Nov 2003, Tom Lane wrote:
Nigel J. Andrews [EMAIL PROTECTED] writes:
On an Intel Linux 2.4.18 I get them quite often, 25 in 1'45, but they
are all just a microsecond.
What do you mean by just a microsecond?
I mean it's always a out of
Tom Lane [EMAIL PROTECTED] writes:
Whoa. Try the following test program.
I tried this on two uniprocessor x86 machines:
(1)
$ uname -a
Linux tokyo 2.6.0-test10 #3 Mon Nov 24 13:43:54 EST 2003 i686 GNU/Linux
This machine produces this output, after running the test app for
about 30 minutes:
On Fri, 28 Nov 2003, Tom Lane wrote:
Nigel J. Andrews [EMAIL PROTECTED] writes:
On Fri, 28 Nov 2003, Tom Lane wrote:
Nigel J. Andrews [EMAIL PROTECTED] writes:
On an Intel Linux 2.4.18 I get them quite often, 25 in 1'45, but they
are all just a microsecond.
What do you mean by just
On Fri, 28 Nov 2003, Darcy Buskermolen wrote:
I've been running this code on a pair of FreeBSD (i386) boxen, for some time
now, one of which is a 4.8-STABLE, the other is a 5.2-BETA.
In 10 minutes of execution the 4.8 box has only shown the following:
out of order tv_sec: 1070063393 115226,
Nigel J. Andrews [EMAIL PROTECTED] writes:
Ah, I have made a mistake. It's only a 2.2.18 kernal. Dual SMP P-III, perhaps
that's the issue there.
Hm. I seem to recall there were still lots of SMP bugs in the 2.2.*
kernels.
And on the FreeBSD system I've got this:
$ time ./a.out 21 | tee
On Fri, 28 Nov 2003, Tom Lane wrote:
Could it be a hardware problem on Marc's box? Or specific to some other
aspect of that installation (Marc, is pgsql74.hub.org multi-CPU, for
example?)
All the servers are SMP ... pgsql74 is on a Dual-Xeon ...
Marc G. Fournier Hub.Org
Marc G. Fournier [EMAIL PROTECTED] writes:
I'm suspecting that the issue is amplified by load on the server itself
That would fit right in with my idea that the failure occurs when the
process loses its timeslice partway through gettimeofday(). Heavier
load would presumably make it more likely
On Fri, 28 Nov 2003, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
I'm suspecting that the issue is amplified by load on the server itself
That would fit right in with my idea that the failure occurs when the
process loses its timeslice partway through gettimeofday(). Heavier
On Fri, 28 Nov 2003, Tom Lane wrote:
Nigel J. Andrews [EMAIL PROTECTED] writes:
$ time ./a.out 21 | tee a.txt
out of order tv_sec: 1070066197 273140, prev 1070066195 721010
out of order tv_usec: 1070066197 273140, prev 1070066195 721010
out of order tv_sec: 1070067322 116061, prev
Marc G. Fournier [EMAIL PROTECTED] writes:
Just got my first response on this, and, in fact, this is 'acceptable
behaviour' to a certain extent ... there is a kernel tuneable called
kern.timecounter.method, that is either 1 or 0:
15 minutes of error is acceptable?
On Fri, 28 Nov 2003, Marc G. Fournier wrote:
On Fri, 28 Nov 2003, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
I'm suspecting that the issue is amplified by load on the server itself
That would fit right in with my idea that the failure occurs when the
process loses its
On Fri, 28 Nov 2003, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
Just got my first response on this, and, in fact, this is 'acceptable
behaviour' to a certain extent ... there is a kernel tuneable called
kern.timecounter.method, that is either 1 or 0:
15 minutes of error
Marc G. Fournier [EMAIL PROTECTED] writes:
15 minutes of error is acceptable?
Apparently *shrug* That was just the first answer back though, so we'll
see what happens ...
BTW, it seems from this thread that the BIND guys have seen even more
bogus behavior than this from gettimeofday() on
On Fri, 28 Nov 2003, Neil Conway wrote:
$ uname -a
FreeBSD home.samurai.com 4.9-RELEASE FreeBSD 4.9-RELEASE #0: Thu Nov 6 21:25:41 EST
2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SAMURAI i386
This machine produces no output after running the test app for about
30 minutes.
what is
Marc G. Fournier [EMAIL PROTECTED] writes:
On Fri, 28 Nov 2003, Neil Conway wrote:
$ uname -a
FreeBSD home.samurai.com 4.9-RELEASE [...]
what is kern.timecounter.method set to?
$ sysctl kern.timecounter.method
kern.timecounter.method: 0
FYI, I ran the test program for another 30 minutes
On Fri, 28 Nov 2003, Neil Conway wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
On Fri, 28 Nov 2003, Neil Conway wrote:
$ uname -a
FreeBSD home.samurai.com 4.9-RELEASE [...]
what is kern.timecounter.method set to?
$ sysctl kern.timecounter.method
kern.timecounter.method: 0
FYI,
Marc G. Fournier [EMAIL PROTECTED] writes:
What kinda processor are you running?
From dmesg:
Timecounter i8254 frequency 1193182 Hz
CPU: Intel Celeron (631.29-MHz 686-class CPU)
Origin = GenuineIntel Id = 0x686 Stepping = 6
29 matches
Mail list logo
