Noah Misch <noah@leadboat.com> writes:
> 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.
Agreed, but actually this isn't just a symptom: the syncscan code is
*causing* full-table heapscans that would not occur otherwise.
>> 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.
As I noted in the other thread, I've had second thoughts about this
proposal: it would serialize incoming sessions even in cases where no
benefit would be gained. Given the lack of previous reports I'm
inclined to think that fixing the misapplication of syncscan logic
should be enough to cure the problem, and hence we shouldn't take a
risk of de-optimizing behavior that has generally worked fine for the
last fifteen years.
regards, tom lane