Re: SetBufferCommitInfoNeedsSave and race conditions

On Fri, 2007-06-29 at 11:13 -0400, Tom Lane wrote:
> "Simon Riggs" <simon(at)2ndquadrant(dot)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