Anton Povarov

Well, it's not perfect :)

i think i have a similar problem and building with -race narrows it down to shared skipBuf, which multiple goroutines use in parallel without locking. even if connection is never...

tried fixing it the naive way, like the go team did - doesn't help with the infinite connection wait, but race goes away.

First, sorry to hijack your thread @vanillar7 ! the minimal example i was able to come up with: https://gist.github.com/anton-povarov/1933714a4dcec96bc0ff steps in the code 1. create X goroutines, intended to consume...

oh, and here's the naive patch i've applied to make the race go away, just in case. https://gist.github.com/anton-povarov/eb7d4a01af4163487c1a

any news, guys ?

thanks, indeed the issue was making too many connections during a very short time, syncookies seem to be the immediate issue. but the underlying one is that syncookies are only...

So 2 cases here 1. query timeouts - i've managed to get them to timeout fine with conn.NetConn().SetDeadline() - just need some way to actually force close the connection this...