SQL backend introduced race detector blind spot. Writes and reads aren't transparent to its ThreadSanitizer internals. Misunderstanding isolation levels and what your application does is the source of nasty race conditions.
I'm thinking a bit, if there's pure go implementation of ACID compliant SQL database with the usual isolation levels (( i.e. read committed, repeatable reads, serializable )) and with keeping the goroutine context (( that is there's no connection pooling, each transaction happens in the new goroutine since this false sharing could lead to false negatives )) the go's race detector could discover bugs across the SQL barrier? The implementation doesn't have to be as performant as production database (( nor does it have to have nice persistence layer )) since it's mostly used for testing and illuminating data race blind spots. Does this make sense or am I speaking bonkers? Is there some project going into this direction? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
