there are no background programs. I've done all the usual checking of
`ps'
outputs looking for such.
in the test case I mailed to this list, I had created a standalone
database
with one table, and run the test program directly against it.
That sounds suspiciously like you think that only backgr
John R Pierce wrote:
About an hour after mailing that, I realized that the buggy RHEL2.1
system was running with Intel Hyperthreading enabled (so it appeared
as 4 CPUs) while the no-problems RH8.0 system had hyperthreading
enabled (we'd previously been benchmarking some multithreaded stuff
both
About an hour after mailing that, I realized that the buggy RHEL2.1
system was running with Intel Hyperthreading enabled (so it appeared as 4
CPUs) while the no-problems RH8.0 system had hyperthreading enabled (we'd
previously been benchmarking some multithreaded stuff both ways). So,
its *ju
John R Pierce wrote:
> *HOWEVER*...
About an hour after mailing that, I realized that the buggy RHEL2.1
system was running with Intel Hyperthreading enabled (so it appeared as
4 CPUs) while the no-problems RH8.0 system had hyperthreading enabled
(we'd previously been benchmarking some multithre
"John R Pierce" <[EMAIL PROTECTED]> writes:
>> You've got some background client holding a transaction open. Or else
>> the test program isn't really committing when you think it is.
> there are no background programs. I've done all the usual checking of `ps'
> outputs looking for such.
> in t
"John R Pierce" <[EMAIL PROTECTED]> writes:
Got something really odd happening here.
Simple test program, in java, with jdbc, postgres 7.4.5, on a redhat
linux
system... app does a heavy loop of a prepared UPDATE, then Commit,
1s
of times. the table has a few columns, nothing fancy at all
"John R Pierce" <[EMAIL PROTECTED]> writes:
> Got something really odd happening here.
> Simple test program, in java, with jdbc, postgres 7.4.5, on a redhat linux
> system... app does a heavy loop of a prepared UPDATE, then Commit, 1s
> of times. the table has a few columns, nothing fanc
Got something really odd happening here.
Simple test program, in java, with jdbc, postgres 7.4.5, on a redhat linux
system... app does a heavy loop of a prepared UPDATE, then Commit, 1s
of times. the table has a few columns, nothing fancy at all.On our
Redhat Enterprise 2.1 server (d