Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id E52766326DC for ; Sat, 21 Aug 2010 23:40:38 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 50505-08 for ; Sun, 22 Aug 2010 02:40:29 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from momjian.us (momjian.us [70.90.9.53]) by mail.postgresql.org (Postfix) with ESMTP id 0A67E632C88 for ; Sat, 21 Aug 2010 23:40:30 -0300 (ADT) Received: (from bruce@localhost) by momjian.us (8.11.6/8.11.6) id o7M2eC728013; Sat, 21 Aug 2010 22:40:12 -0400 (EDT) From: Bruce Momjian Message-Id: <201008220240.o7M2eC728013@momjian.us> Subject: Re: Return of the Solaris vacuum polling problem -- anyone remember this? In-Reply-To: <4C6C2E4A.1010506@agliodbs.com> To: Josh Berkus Date: Sat, 21 Aug 2010 22:40:12 -0400 (EDT) CC: Tom Lane , PostgreSQL-development X-Mailer: ELM [version 2.4ME+ PL124 (25)] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="ELM1282444812-26643-0_" Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.91 tagged_above=-5 required=5 tests=BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201008/1592 X-Sequence-Number: 168395 --ELM1282444812-26643-0_ Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Josh Berkus wrote: > > > On further reflection, though: since we put in the BufferAccessStrategy > > code, which was in 8.3, the background writer isn't *supposed* to be > > very much involved in writing pages that are dirtied by VACUUM. VACUUM > > runs in a small ring of buffers and is supposed to have to clean its own > > dirt most of the time. So it's wrong to blame this on the bgwriter not > > holding up its end. Rather, what you need to be thinking about is how > > come vacuum seems to be making lots of pages dirty on only one of these > > machines. > > This is an anti-wraparound vacuum, so it could have something to do with > the hint bits. Maybe it's setting the freeze bit on every page, and > writing them one page at a time? Still don't understand the call to > pollsys, even so, though. We often mention that we do vacuum freeze for anti-wraparound vacuum, but not for pg_clog file removal, which is the primary trigger for autovacuum vacuum freezing. I have added the attached documentation patch for autovacuum_freeze_max_age; back-patched to 9.0. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + --ELM1282444812-26643-0_ Content-Transfer-Encoding: 7bit Content-Type: text/x-diff Content-Disposition: inline; filename="/rtmp/diff" Index: doc/src/sgml/config.sgml =================================================================== RCS file: /cvsroot/pgsql/doc/src/sgml/config.sgml,v retrieving revision 1.304 diff -c -c -r1.304 config.sgml *** doc/src/sgml/config.sgml 17 Aug 2010 04:37:20 -0000 1.304 --- doc/src/sgml/config.sgml 22 Aug 2010 02:30:39 -0000 *************** *** 4150,4156 **** Specifies the maximum age (in transactions) that a table's pg_class.relfrozenxid field can ! attain before a VACUUM operation is forced to prevent transaction ID wraparound within the table. Note that the system will launch autovacuum processes to prevent wraparound even when autovacuum is otherwise disabled. --- 4150,4157 ---- Specifies the maximum age (in transactions) that a table's pg_class.relfrozenxid field can ! attain before a VACUUM operation is forced to allow removal ! of old files from the pg_clog subdirectory and prevent transaction ID wraparound within the table. Note that the system will launch autovacuum processes to prevent wraparound even when autovacuum is otherwise disabled. --ELM1282444812-26643-0_--