Re: Inaccuracy in VACUUM's tuple count estimates

On 2014-06-09 10:30:43 -0400, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> > On 2014-06-09 10:14:32 -0400, Robert Haas wrote:
> >> I think that would be a good idea for conceptual clarity if nothing
> >> else. If callers are OK with it, then they can treat both of those
> >> codes alike; but then at least there's clear evidence as to the
> >> author's intent.
>
> > I am happy to introduce the code for that. But it'd have to be >=9.4 or
> > 9.4?
>
> We need a solution that can be back-patched, unless you're prepared to
> revert what you already did to HTSV in the back branches.

Well, I think reverting surely wouldn't be the right cure. It fixes a
somewhat nasty bug. I'd certainly be prepared to add the two lines
necessary to make it return DELETE_IN_PROGRESS after trying to
understand Kevin's email about predicate.c and going through the other
callers another time.
I did ask about what people think is the more appropriate return
value. And the only person that had voiced an opinion was Alvaro
agreeing that it's more correct to return INSERT_IN_PROGRESS... Don't
make this about me insisting on anything.

> Having said that, it's not clear to me that we couldn't change HTSV's
> API in the back branches. What third-party code would be likely to
> be depending on it?

I'm not sure. I could imagine tools like pg_repack depending on it (it
doesn't). I started to search for external users of the function and
have only found a bunch of forks of postgres so far. Several of which
I've never heard of before.
I think it's more reasonable to return DELETE_IN_PROGRESS in existing
branches and then go the new return value in 9.5 or maybe 9.4.

Greetings,

Andres Freund

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