Re: Inaccuracy in VACUUM's tuple count estimates - Mailing list pgsql-hackers

On 2014-06-06 15:44:25 -0400, Tom Lane wrote:
> I figured it'd be easy enough to get a better estimate by adding another
> counter to count just LIVE and INSERT_IN_PROGRESS tuples (thus effectively
> assuming that in-progress inserts and deletes will both commit).  I did
> that, and found that it helped Tim's test case not at all :-(.  A bit of
> sleuthing revealed that HeapTupleSatisfiesVacuum actually returns
> INSERT_IN_PROGRESS for any tuple whose xmin isn't committed, regardless of
> whether the transaction has since marked it for deletion:
> 
>             /*
>              * It'd be possible to discern between INSERT/DELETE in progress
>              * here by looking at xmax - but that doesn't seem beneficial for
>              * the majority of callers and even detrimental for some. We'd
>              * rather have callers look at/wait for xmin than xmax. It's
>              * always correct to return INSERT_IN_PROGRESS because that's
>              * what's happening from the view of other backends.
>              */
>             return HEAPTUPLE_INSERT_IN_PROGRESS;

That's only the case of a couple of days ago. I really wasn't sure
wheter to go that way or discern the two cases. That changed in the wake
of:
http://www.postgresql.org/message-id/20140530143150.GA11051@localhost

I tried to solicit feedback (e.g. by CCing you :)) but I mostly
failed. Alvaro agreed, on IM, that it's better this way.

> It did not use to blow this question off: back around 8.3 you got
> DELETE_IN_PROGRESS if the tuple had a delete pending.  I think we need
> less laziness + fuzzy thinking here.

My argument for not discerning wasn't that it's hard to do, but that it
might confuse callers more the other way round. E.g. doing a
XactLockTableWait(xmax) might not be sufficient for the tuple being
alive.


> Maybe we should have a separate
> HEAPTUPLE_INSERT_AND_DELETE_IN_PROGRESS result code?

Maybe.

> Is it *really*
> the case that callers other than VACUUM itself are okay with failing
> to make this distinction?  I'm dubious: there are very few if any
> callers that treat the INSERT and DELETE cases exactly alike.

I looked through all of them and saw none that'd be problematic. And
some, like predicate.c, where the new behaviour seems to be better. Most
of the ones that care about INSERT/DELETE_IN_PROGRESS wait on xmin/xmax
respectively.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services