Skip site navigation (1) Skip section navigation (2)

Re: vacuum problem

From: "John R Pierce" <pierce(at)hogranch(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "pgsql -bugs" <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: vacuum problem
Date: 2004-09-11 04:23:33
Message-ID: 01a501c497b7$1984f610$ (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
> "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.


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. 

In response to


pgsql-bugs by date

Next:From: Bruce MomjianDate: 2004-09-11 07:05:28
Subject: Re: Can't run 8.0 ....
Previous:From: Tom LaneDate: 2004-09-11 01:58:48
Subject: Re: bug-report-template

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group