On Sat, May 26, 2012 at 03:14:18PM -0400, Tom Lane wrote:
> It seems clear to me that we should just disable syncscans for the
> relcache reload heapscans. There is lots of downside due to breaking
> the early-exit optimization in RelationBuildTupleDesc, and basically no
> upside. I'm inclined to just modify systable_beginscan to prevent use
> of syncscan whenever indexOK is false. If we wanted to change its API
> we could make this happen only for RelationBuildTupleDesc's calls, but
> I don't see any upside for allowing syncscans for other forced-heapscan
> callers either.
Looks harmless enough, though it's only targeting a symptom. No matter how
you cut it, the system is in a bad state when many backends simultaneously
heapscan a large system catalog.
> 2. The larger problem here is that when we have N incoming connections
> we let all N of them try to rebuild the init file independently. This
> doesn't make things faster for any one of them, and once N gets large
> enough it makes things slower for all of them. We would be better off
> letting the first arrival do the rebuild work while the others just
> sleep waiting for it. I believe that this fix would probably have
> ameliorated Jeff and Greg's cases, even though those do not seem to
> have triggered the syncscan logic.
This strikes me as the clearer improvement; it fixes the root cause.
Thanks,
nm