Re: Weird planner issue on a standby

Peter Geoghegan <pg(at)bowt(dot)ie> writes:
> That's true, but it doesn't matter whether or not there are LP_DEAD
> bits set on the standby, since in any case they cannot be trusted when
> in Hot Standby mode. IndexScanDescData.ignore_killed_tuples will be
> set to false on the standby.

Hmm. I think that might break this argument in get_actual_variable_endpoint:

* A crucial point here is that SnapshotNonVacuumable, with
* GlobalVisTestFor(heapRel) as horizon, yields the inverse of the
* condition that the indexscan will use to decide that index entries are
* killable (see heap_hot_search_buffer()). Therefore, if the snapshot
* rejects a tuple (or more precisely, all tuples of a HOT chain) and we
* have to continue scanning past it, we know that the indexscan will mark
* that index entry killed. That means that the next
* get_actual_variable_endpoint() call will not have to re-consider that
* index entry. In this way we avoid repetitive work when this function
* is used a lot during planning.

However, that doesn't explain the downthread report that a
VACUUM on the primary fixed it. What I suspect is that that
caused some in-fact-dead index entries to get cleaned out.

But ... if the primary is allowed to vacuum away an index
entry that it thinks is dead, exactly what is the point of
making standbys ignore LP_DEAD bits? There's no additional
interlock that guarantees the tuple will be there at all.

regards, tom lane