This library does not contain any locking code to protect objects against simultaneous modification in multi-threaded programs.

There are many different threading interfaces and libpqxx does not dictate your choice.

Therefore it is up to you, the user of the library, to ensure that your threaded client programs perform no conflicting operations concurrently.

The library does try to avoid non-obvious unsafe operations and so does the underlying libpq. Here's what you should do to keep your threaded libpqxx application safe:

Treat a connection, together with any and all objects related to it, as a "world" of its own. You should generally make sure that the same "world" is never accessed concurrently by multiple threads. There are a few cases where you don't need to be this careful, however; see below.

Result sets (pqxx::result) and binary data (pqxx::binarystring) are special. Copying these objects is very cheap, and you can give the copy to another thread. Just make sure that no other thread accesses the same copy when it's being assigned to, swapped, cleared, or destroyed.

Warning: Prior to libpqxx 3.1, or in C++ environments without the standard "shared_ptr" smart pointer type, copying, assigning, or destroying a pqxx::result or pqxx::binarystring could also affect any other other object of the same type referring to the same underlying data.

Use pqxx::describe_thread_safety to find out at runtime what level of thread safety is implemented in your build and version of libpqxx. It returns a pqxx::thread_safety_model describing what you can and cannot rely on. A command-line utility tools/pqxxthreadsafety prints out the same information.