Jeff Boes <jboes@nexcerpt.com> writes:
> ERROR: No one parent tuple was found
> NOTICE: Child itemid in update-chain marked as unused -
> can't continue repair_frag
> Are these problems serious? Should I just ignore them until we go to 7.3?
No; yes. They've been "fixed" in 7.3 by the simple expedient of
downgrading the messages to DEBUG level ;-). The reason is that these
are in fact not unexpected cases. The 7.3 source code explains:
* NOTE: this test is not 100% accurate: it is possible for a
* tuple to be an updated one with recent xmin, and yet not
* have a corresponding tuple in the vtlinks list. Presumably
* there was once a parent tuple with xmax matching the xmin,
* but it's possible that that tuple has been removed --- for
* example, if it had xmin = xmax then
* HeapTupleSatisfiesVacuum would deem it removable as soon as
* the xmin xact completes.
*
* To be on the safe side, we abandon the repair_frag process if
* we cannot find the parent tuple in vtlinks. This may be
* overly conservative; AFAICS it would be safe to move the
* chain.
Since the set of tuples deemed "recent" depends on the age of the oldest
open transaction, having long-running transactions open concurrently
with your VACUUM FULL considerably increases the odds of such trouble.
Dunno if that describes your situation, or if there's anything you can
do to change it if it is, but it's the only tip I can offer.
Really my feeling about it is you shouldn't be doing VACUUM FULL on
heavily-used tables anyway --- lazy VACUUM is what to be using.
If that fails to keep the table size reasonable, that means you aren't
doing it often enough or don't have a large enough FSM.
regards, tom lane