Re: pgsql: Avoid marking buffer dirty when VACUUM has no work to do.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: pgsql-committers(at)postgresql(dot)org
Subject: Re: pgsql: Avoid marking buffer dirty when VACUUM has no work to do.
Date: 2011-11-18 16:19:04
Message-ID: 18255.1321633144@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> Avoid marking buffer dirty when VACUUM has no work to do.
> When wal_level = 'hot_standby' we touched the last page of the
> relation during a VACUUM, even if nothing else had happened.
> That would alter the LSN of the last block and set the mtime
> of the relation file unnecessarily. Noted by Thom Brown.

This doesn't look right to me --- you have not accounted for the
possibility that btpo_cycleid or BTP_HAS_GARBAGE is changed.

Also, I'm confused about the business of not setting the LSN. Thom
claimed that he was seeing the page not change at all (or at least
md5sum of the file didn't change) despite mtime changing. If we'd
been plastering a new LSN on the page each time, then that should
certainly not have been possible. So I now think maybe we've
mis-analyzed what was happening in his example.

I think this requires more careful analysis.

regards, tom lane

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2011-11-18 23:24:48 pgsql: Further review of range-types patch.
Previous Message Simon Riggs 2011-11-18 16:09:57 pgsql: Avoid marking buffer dirty when VACUUM has no work to do.

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2011-11-18 16:26:02 Re: testing ProcArrayLock patches
Previous Message David Zwarg 2011-11-18 16:17:13 OidFunctionCall* returning null.