Gregory Stark <stark@enterprisedb.com> writes:
> "Tom Lane" <tgl@sss.pgh.pa.us> writes:
>> I went through all of the heap_beginscan calls in the code last night.
>> pgstattuple was broken but AFAICS none of the other callers care about
>> the visitation order. I wonder though about third-party add-ons :-(
> Perhaps we ought to have made heap_beginscan guarantee an ordered scan and
> made synch scans be explicitly requested. That would have touched a lot of
> lines but been more conservative. I'm not sure it's worth going back on it now
> though.
Hmm. I'm too lazy to go back and look right now, but IIRC most of the
hardwired heapscans are on system catalogs that are unlikely to be large
enough to trigger a syncscan anyway. If we were to flip the semantics,
and then change only the callers that clearly need to enable syncscans,
it would not be all that large a patch I think.
On the other hand it's far from clear that there's really a problem.
The model for doing a block-at-a-time scan is VACUUM, and that doesn't
use the heapscan infrastructure but just fetches blocks by number.
It would only be people who'd copied pgstattuple's methodology that
would be likely to be at risk. I'm not sure we should protect those
hypothetical people at the cost of not doing syncscans for other
(also hypothetical) third-party add-ons that do heapscans on large
tables and wouldn't have a problem with wraparound.
It's a tossup from here. Anybody have a strong opinion one way or the
other?
regards, tom lane