Re: Unexpected VACUUM FULL failure - Mailing list pgsql-hackers

"Simon Riggs" <simon@2ndquadrant.com> writes:
> On Fri, 2007-08-10 at 11:11 -0400, Tom Lane wrote:
>> If we do that, we don't actually need XLogAsyncCommitFlush() at the start.
>> I'm inclined to remove it just because it's ugly.  Comments?

> I'm not clear why XLogAsyncCommitFlush() is ugly. It's one line of code
> that doesn't make anything else any harder. Apart from system catalogs,
> doing it that way would be error free for all normal VFs.

Please recall that the failure that started this thread was on a regular
user table.  To do what you want will introduce what I'm now thinking
is an unacceptable amount of fragility.  In particular your patch of
yesterday to force hint-bit setting in VF scares the heck out of me.

The reason why XLogAsyncCommitFlush() is ugly is that it doesn't
actually accomplish a darn thing, as we now see from this failure:
it does not guarantee that hint bits will get set, because of the
inexact bookkeeping in clog.c.  It might marginally improve the
probability that they get set, but that's all.  The reason I want
to take it out is mainly that its very existence tempts people to make
the same mistake that was made here.

> I now think we *must* do this for system catalogs, or something else at
> least. Personally I would prefer preventing async commits from occurring
> when a system catalog has been touched at all, which would make the VF
> situation and a few other situations go away entirely.

I think that that is completely the wrong line of thought: we should be
making async commit work everywhere, or as nearly so as possible, not
inventing arbitrary restrictions to place on it.  The restriction
you suggest here would probably cost more performance (by forcing sync
commits) than could ever be gained back by being able to assume hint
bits are set.  In the patch as committed, I took out most of the
restrictions you had on async commit --- the only utility commands that
force sync commit are the ones that have direct effects on the filesystem.

Another argument is that VACUUM FULL is a dinosaur that should probably
go away entirely someday (a view I believe you share); it should
therefore not be allowed to drive the design of other parts of the
system.
        regards, tom lane