Re: Inaccuracy in VACUUM's tuple count estimates

Kevin Grittner wrote:
> Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> > On 2014-06-09 09:45:12 -0700, Kevin Grittner wrote:

> >>> old:
> >>> 1) xmin has committed, xmax is in progress, xmax is not just a locker
> >>> 2) xmin is in progress, xmax is set and not not just a locker
> >>>
> >>> Note that the 2) case here never checked xmax's status.
> >>
> >>  Again, I'm not sure how 2) could happen unless they involve the
> >>  same top-level transaction.  What am I missing?
> >
> > Right, both can only happen if the tuple is created & deleted in the
> > same backend. Is that in contradiction to something you see?
>
> Well, you're making a big point that the status of xmax was not
> checked in the old code.  If xmax is the same as xmin and xmin is
> in progress, the additional check seems redundant -- unless I'm
> missing something.

IIRC the case that prompted the fix was a CREATE INDEX in the same
transaction that created a tuple which was later deleted by an aborted
subtransaction. If the creating transaction is not this backend, that's
fine. But if the creating transaction IsCurrentTransactionId() then we
need to be careful about aborted subxacts: if a tuple was deleted by an
aborted subxact then it's still visible to this transaction. Xmax must
be checked in this case. Note that the difference is pretty specific to
CREATE INDEX. Vacuuming doesn't have to worry about such cases, mainly
because you can't run vacuum in a transaction.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services