It might be done in the other direction, though - the "writer" thread
might collect current results at the end of the interval.
Yep, you can indeed accumulate per thread and sum on the end of the
interval, but a lock is still needed if you want exact figures.
ISTM that it is what is done for --progress, without even bothering to
lock anything (even if transactions are fast and some inconsistency arise,
this is just for showing how things are faring on stderr, so no big deal).
"fprintf" does a lot of processing, so it is the main issue.
The question is whether the processing happens while holding the lock,
though. I don't think that's the case.
Alas I'm pretty nearly sure it is necessarily the case, there is no
intermediate buffer in fprintf, the buffering is done trough the file
handler so a lock must be acquire throughout format processing.
https://www.gnu.org/software/libc/manual/html_node/Streams-and-Threads.html#Streams-and-Threads
"The POSIX standard requires that by default the stream operations are
atomic. I.e., issuing two stream operations for the same stream in two
threads at the same time will cause the operations to be executed as if
they were issued sequentially. The buffer operations performed while
reading or writing are protected from other uses of the same stream. To do
this each stream has an internal lock object which has to be (implicitly)
acquired before any work can be done. "
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
