I don't quite understand the new call in gininsert -- I mean I see that it wants to check for conflicts even when fastupdate is set, but why? Maybe, just maybe, it would be better to add a new flag to the GinCheckForSerializableConflictIn function, that's passed differently for this one callsite, and then a comment next to it that indicates why do we test for fastupdates in one case and not the other case. If you don't like this idea, then I think more commentary on why fastupdate is not considered in gininsert is warranted.
In startScanEntry, if you "goto restartScanEntry" in the fastupdate case, are you trying to acquire the same lock again? Maybe the lock acquire should occur before the goto target? (If this doesn't matter for some reason, maybe add a comment about it) -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
