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

Re: VACUUM touching file but not updating relation

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Thom Brown <thom(at)linux(dot)com>, PGSQL Mailing List <pgsql-general(at)postgresql(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: VACUUM touching file but not updating relation
Date: 2011-11-22 09:31:39
Message-ID: CA+U5nM+i3XtMFEXD4+T-sj8o1PkXYsB5CSwDUipJcqofjbjvYg@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-hackers
On Fri, Nov 18, 2011 at 3:18 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

>> So the correct number of WAL records is emitted and I see no bug there.
>
> What Thom's complaining about is that the buffer may be marked dirty
> unnecessarily, ie when there has been no actual data change.

Based upon both your feedback, I made a change to stop the block being
marked dirty, though Tom now wants that removed.

Thom, your earlier analysis showing that the md5 checksum of a
relation had changed is not happening because of the section of code
you identified. The code sets some data on the page, which would cause
the md5 checksum to change. So it cannot be the btree code  at
_bt_delitems_vacuum() causing this.

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

In response to

pgsql-hackers by date

Next:From: Simon RiggsDate: 2011-11-22 09:36:52
Subject: Re: [COMMITTERS] pgsql: Avoid marking buffer dirty when VACUUM has no work to do.
Previous:From: Dean RasheedDate: 2011-11-22 07:49:49
Subject: Re: Singleton range constructors versus functional coercion notation

pgsql-general by date

Next:From: Siva PalanisamyDate: 2011-11-22 09:32:59
Subject: Why CASCADE constraint takes more time when table is loaded with huge records?
Previous:From: Simon RiggsDate: 2011-11-22 09:11:13
Subject: Re: [general] rsync'd database requires reindex - why ?

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