Data race in interfaces/libpq/fe-exec.c - Mailing list pgsql-hackers

triggers data race errors when run under ThreadSanitizer (*)

As far as I can tell, the static variable in question is a hack to allow a couple of deprecated functions that are already unsafe to use (PQescapeString and PQescapeBytea) to be fractionally less unsafe to use.

Would there be any interest in a patch changing the type of static_client_coding and static_std_strings to some atomic equivalent, so the data race goes away?

I know that as long as clients aren't daft enough to call PQescapeString or PQescapeBytea, then the static variables are write-only - but wiser heads than mine assure me that even if nothing ever reads from the variables, unguarded simultaneous writes can cause issues when built with particularly aggressive compilers... On the plus side: "As a note for changing the variable to be atomic - if it uses acquire-release semantics, it'll be free on x86 (barring any potential compiler optimisations that we want to stop). And relaxed semantics should be free everywhere."

And it would be nice to be able to keep running my postgres-using tests under ThreadSanitizer...

thanks

Mark

(*) specifically in a test that kicks off two simultaneous threads whose first action is to open a postgres connection.