To: Josh Berkus <josh@agliodbs.com>
cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: Return of the Solaris vacuum polling problem -- anyone remember
	this?
In-reply-to: <4C6C2E4A.1010506@agliodbs.com> 
References: <4C69827A.409@agliodbs.com> <19969.1281986537@sss.pgh.pa.us>
	<4C6C2B2B.9060501@agliodbs.com> <8599.1282158010@sss.pgh.pa.us>
	<4C6C2E4A.1010506@agliodbs.com>
Comments: In-reply-to Josh Berkus <josh@agliodbs.com>
	message dated "Wed, 18 Aug 2010 12:02:34 -0700"
Date: Wed, 18 Aug 2010 15:07:59 -0400
Message-ID: <8807.1282158479@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Josh Berkus <josh@agliodbs.com> writes:
>> 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?

That would explain all the writes, but it doesn't seem to explain why
your two servers aren't behaving similarly.

> Still don't understand the call to pollsys, even so, though.

Most likely that's the libc implementation of the select()-based sleeps
for vacuum_cost_delay.  I'm still suspicious that the writes are eating
more cost_delay points than you think.

			regards, tom lane