On Sat, April 2, 2011 22:30, Tom Lane wrote: >> Have you tried upping the aggressiveness of autovacuum? >> > > I'm wondering about poor selection of the cost_delay settings in > particular. It's quite easy to slow autovacuum to the point that it takes > forever to do anything. It's been on the default 20ms. Now giving 0 a try. In our app responsiveness is less of a concern since we don't have human interaction. Reliability is a greater concern. > It's also possible that Henry is getting bit by the bug fixed here: > > > Author: Tom Lane <tgl@xxxxxxxxxxxxx> > Branch: master [b58c25055] 2010-11-19 22:28:20 -0500 > Branch: REL9_0_STABLE Release: REL9_0_2 [b5efc0940] 2010-11-19 22:28:25 -0500 > Branch: REL8_4_STABLE Release: REL8_4_6 [fab2af30d] 2010-11-19 22:28:30 -0500 > Branch: REL8_3_STABLE Release: REL8_3_13 [6cb9d5113] 2010-11-19 22:28:35 -0500 > > > Fix leakage of cost_limit when multiple autovacuum workers are active. I'm using 9.0.3, and typically (when things eventually deteriorate to a impending-wraparound situation) there are at least 2 and sometimes a few more autovac procs running - some of them for weeks). Anyway, time will now tell whether a cost_delay of 0 and some more SSDs will help prevent hitting the wraparound wall. Cheers h -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
