The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/17/libpq-threading.html Description:
commit https://github.com/postgres/postgres/commit/515112f9d4874aaedd0c093f41c0ba3e0bf7f660 added global variables for backward compatibility support: static_client_encoding, static_std_strings If multiple threads are creating connections at the same time, this can result in a data race in pqSaveParameterStatus where both attempts to connect try to set those global variables. If those are the same value for all users of the library, this might be okay. This is mentioned in the commit comment: > This will work reliably in clients using only one Postgres connection at a time, or even multiple connections if they all use the same encoding and string syntax settings; which should cover many practical scenarios. But it does not cover the other use cases, where all uses in the program do not have the same settings. Additionally, this implementation causes thread sanitizer tests to fail, even in the 'safe' use case. A data race occurs and is flagged as an error when multiple threads connect at the same time and attempt to update the global variable. The documentation at https://www.postgresql.org/docs/current/libpq-threading.html does not reference this issue at all, and in fact suggests to create multiple connections. There is no clear workaround within the library for the 'safe' method other than locking the connection generators, or marking this tsan error as acceptable. There does not seem to be a workaround at all for the 'unsupported' case. At the very least, I would suggest update the threading documentation with this usage caveat.
