Re: Inaccuracy in VACUUM's tuple count estimates

Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> On 2014-06-09 09:45:12 -0700, Kevin Grittner wrote:
>> For purposes of predicate.c, if the "also deleted" activity might
>> be rolled back without rolling back the insert, INSERT_IN_PROGRESS
>> is the only correct value.

> That's basically the argument for the new behaviour.

> But I am not sure, given predicate.c's coding, how
> HEAPTUPLE_DELETE_IN_PROGRESS could cause problems. Could you elaborate,
> since that's the contentious point with Tom? Since 'both in progress'
> can only happen if xmin and xmax are the same toplevel xid and you
> resolve subxids to toplevel xids I think it should currently be safe
> either way?

Assuming that Kevin's describing his needs correctly, we could resolve
this by inventing HEAPTUPLE_INSERT_AND_DELETE_IN_PROGRESS. VACUUM could
assume that that's a probably-dead tuple, while SSI could do something
different. I'm not sure if it's worth special-casing xmin == xmax,
where the tuple is guaranteed to never be of interest to any other
transaction?

The reason this stuff is not too carefully spec'd is that when HTSV
was written, there was no expectation that there was any correctness
issue around which of these cases was returned. I wonder whether SSI
should be using HTSV at all.

regards, tom lane