Re: vacuum problem

> "John R Pierce" <pierce(at)hogranch(dot)com> 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,
>> 10000s
>> of times. the table has a few columns, nothing fancy at all. On our
>> Redhat Enterprise 2.1 server (dual xeon, 3GB ram, etc), I can't vacuum
>> the
>> table it generates, it won't free the 'dead' rows...
>
> 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 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.

*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 multithreaded stuff both ways). So, its
*just* possible that the earlier RHEL2.1 (kernel 2.4.9-e.43enterprise) had
issues which the later RH8 (2.4.20-28.8smp) were resolved. I'll not be
able to test this hypothesis until monday morning.