Re: Damage control for planner's get_actual_variable_endpoint() runaway

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> I don't think this is safe at all. Wait events can only bracket
> individual operations, like the reads of the individual index blocks,
> not report on which phase of a larger operation is in progress. If we
> try to make them do the latter, we will have a hot mess on our hands.

Agreed.

> What we need is a solution that avoids reading an unbounded number of
> tuples under any circumstances. I previously suggested using
> SnapshotAny here, but Tom didn't like that. I'm not sure if there are
> safety issues there or if Tom was just concerned about the results
> being misleading. Either way, maybe there's some variant on that theme
> that could work. For instance, could we teach the index scan to stop
> if the first 100 tuples that it finds are all invisible? Or to reach
> at most 1 page, or at most 10 pages, or something?

A hard limit on the number of index pages examined seems like it
might be a good idea.

> If we don't find a
> match, we could either try to use a dead tuple, or we could just
> return false which, I think, would end up using the value from
> pg_statistic rather than any updated value.

Yeah, the latter seems like the best bet. Returning a definitely-dead
value could be highly misleading. In the end this is meant to be
an incremental improvement on what we could get from pg_statistic,
so it's reasonable to limit how hard we'll work on it.

If we do install such a thing, should we undo any of the previous
changes that backed off the reliability of the result?

regards, tom lane