On Mon, Jan 14, 2008 at 10:10:54PM -0500, Tom Lane wrote:
> 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
>
The principle of least surprise would have us default to syncscans and
assume that the 3rd-party add-ons can or will handle the wraparound.
This choice at least helps to bound the resource usage by many simultaneous
scans, speaking as someone who has brought a server to its knees using
multiple full-table scans.
Cheers,
Ken Marshall
