hyc@symas.com wrote:

Fixing this issue would require a complete redesign of the psearch queue handling. Instead of queuing up a separate response per psearch, there should be a single queue of responses, and the qplayer should iterate thru to match a response to each of the active psearches. That would guarantee that all replicas receive a given change before any of them receives the next change. This would also help with the ordering issues discussed recently on -technical and -devel.

Except that this would also force all replication to run at the speed of the slowest consumer...

I suspect this is too big a change to target the next (.16) release, since we're focusing on re-stabilizing the code right now.

The new code in HEAD is actually simpler now, it just pushes ops into the thread pool. Please test...