Currently, I'm seeing the psecure_{red,write} functions being invoked when connecting to postgres via a unix domain socket. psecure_write seems to alter the signal mask of the process to disable sigpipe reporting. psecure_read only does this when the connection is using SSL.
When using a multithreaded client application on Linux, this can result in poor scalability. Each change to the signal mask requires an current->sighand->siglock, which becomes highly contended between the client threads. It also means we do 3 syscalls per write: mask sigpipe, write, unmask sigpipe. The following patch changes psecure_write to be more like psecure_read - it only alters the signal mask if the connection is over SSL. It's only an RFC, as I'm not entirely sure about the reasoning behind blocking SIGPIPE for the non-SSL case - there may be other considerations here. With this change I see the following performance improvement during a sysbench OLTP run: http://ozlabs.org/~jk/projects/db/data/sigpipe-perf.png load: sysbench --test=oltp --oltp-read-only=on, connecting locally, machine: POWER6, 64-way, 4.2GHz Comments most welcome, Jeremy --- Jeremy Kerr (1): Only disable sigpipe during SSL write -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers