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

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

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [COMMITTERS] pgsql: Avoid marking buffer dirty when VACUUM has no work to do.
Date: 2011-11-22 09:36:52
Message-ID: CA+U5nMKETN2Um8dsPhCm3T-axG_F9PyMmuZrgUArpX4dhrdDZg@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
On Tue, Nov 22, 2011 at 2:32 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I wrote:
>> 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.
>
> Ping?  If you don't respond, I'm going to take it on my own authority to
> revert this patch, because it's definitely broken as-is, and I don't
> think the consequences of not updating the page LSN have been thought
> through either.

Tom, waiting across a weekend isn't a cause for concern.

I made that change for you, so am happy to revoke for you also.

-- 
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

In response to

pgsql-hackers by date

Next:From: Kyotaro HORIGUCHIDate: 2011-11-22 10:56:55
Subject: Re: Allow substitute allocators for PGresult.
Previous:From: Simon RiggsDate: 2011-11-22 09:31:39
Subject: Re: VACUUM touching file but not updating relation

pgsql-committers by date

Next:From: Simon RiggsDate: 2011-11-22 09:48:54
Subject: pgsql: Continue to allow VACUUM to mark last block of index dirty
Previous:From: Tom LaneDate: 2011-11-22 02:32:44
Subject: Re: [COMMITTERS] pgsql: Avoid marking buffer dirty when VACUUM has no work to do.

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