Re: SetBufferCommitInfoNeedsSave and race conditions - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: SetBufferCommitInfoNeedsSave and race conditions
Date
Msg-id 1183399489.4146.30.camel@silverbirch.site
Whole thread Raw
In response to Re: SetBufferCommitInfoNeedsSave and race conditions  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, 2007-06-29 at 11:13 -0400, Tom Lane wrote:
> "Simon Riggs" <simon@2ndquadrant.com> writes:
> > On Thu, 2007-06-28 at 20:23 -0400, Tom Lane wrote:
> >> 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.
> 
> > 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.
> 
> I don't believe this is correct (see system catalogs) and in any case
> it's far too fragile for my taste.  I think it'd be a lot better to just
> stop referencing the hint bits directly in VACUUM FULL.

Well, according to the comments in repair_frag(), line 1799-1815,
specifically line 1810 says "we wouldnt be in repair_frag() at all" if
the tuple was "in a system catalog, inserted or deleted by a not yet
committed transaction". If we have flushed all committed and/or aborted
transactions then we're good.

Maybe the comment is wrong? Wouldn't be the first time. Either way,
please explain your concern in more detail.

I'd rather do this the easy way since VF seems soon to die (payback for
all the torture its caused us down the years).

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




pgsql-hackers by date:

Previous
From: "Simon Riggs"
Date:
Subject: Re: Configurable Additional Stats
Next
From: "Pavel Stehule"
Date:
Subject: Re: what is difference between LOCAL and GLOBAL TEMP TABLES in PostgreSQL