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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers