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

Re: SetBufferCommitInfoNeedsSave and race conditions

From: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>,"Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com>,"PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SetBufferCommitInfoNeedsSave and race conditions
Date: 2007-06-29 14:15:33
Message-ID: 1183126533.3589.129.camel@silverbirch.site (view raw or flat)
Thread:
Lists: pgsql-hackers
On Thu, 2007-06-28 at 20:23 -0400, Tom Lane wrote:
> "Simon Riggs" <simon(at)2ndquadrant(dot)com> writes:
> > On Thu, 2007-06-28 at 15:16 -0400, Tom Lane wrote:
> >> A quick grep suggests that VACUUM FULL might be at risk here.
> 
> > No we're clear: I caught that issue specifically for VACUUM FULL fairly
> > early on. VF assumes all hint bits are set after the first scan, so we
> > flush prior to the scan to ensure its safe to set the hint bits.
> 
> Flush what prior to the scan?
> 
> The methodology I suggested earlier (involving tracking LSN only at the
> level of pg_clog pages) isn't going to make that work, unless you
> somehow force the XID counter forward to the next page boundary.
> It might be that that level of tracking is too coarse anyway, since
> it essentially says that you can't hint any transaction until the
> next 32K-transaction boundary is reached.

If you completely flush WAL after the AccessExclusiveLock has been taken
by VF, then you are guaranteed to have flushed all asynchronous commits
that touch the table.

You're right that I just broke VF again by changing the implementation
back to deferred hint setting. I'll fix again. Hmmm, I can add a test
for LockHeldByMe(AccessExclusiveLock) in tqual, or just have a
VacuumHintStrategy() call that alters the behaviour of the tqual
routines. Latter sounds best?

My aim is to get this all wrapped up by end of Monday night.

-- 
  Simon Riggs             
  EnterpriseDB   http://www.enterprisedb.com



In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2007-06-29 14:57:43
Subject: Re: pg_dump and minor versions
Previous:From: Bernd HelmleDate: 2007-06-29 13:57:01
Subject: Re: pg_dump and minor versions

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