"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, 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.
---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
