I'm worried about libpq blocking in some circumstances; particularly
around SSL renegotiations.
This came up while writing an async postgres library for lua, I
realised that this code was dangerous:
https://github.com/daurnimator/cqueues-pgsql/blob/ee9c3fc85c94669b8128386d99d730fe93d9dbad/cqueues-pgsql.lua#L121
e.g. 1:
When a PQ connection is in non-blocking mode, PQflush returns 1, the docs say:
> wait for the socket to be write-ready and call it again
However, if the SSL layer is waiting on data for a renegotiation,
write readiness is not enough:
Waiting for POLLOUT and calling PQflush again will (untested) just
return 1 again, and continue to do so until data is recieved.
This is a busy-loop, and will block the host application.
e.g. 2:
An SSL renegiation happens while trying to receive a response.
According to 'andres' on IRC, inside of `PQisBusy` there is a busy loop:
> 14:22:32 andres You'll not see that. Even though the explanation for it is absolutely horrid.
> 14:23:32 andres There's a busy retry loop because of exactly that reason inside libpq's ssl read function whenever it
hitsa WANT_WRITE.
> 14:23:58 daurnimator so... libpq will block my process? :(
> 14:24:25 andres daurnimator: That case is unlikely to be hit often luckily because of the OS buffering. But yea, it's
reallyunsatisfying.
> 14:26:06 andres daurnimator: I think this'll need a new API to be properly fixed.
One idea that came to mind if we want to keep the same api, is to hide
the socket behind an epoll file descriptor,
they always poll read ready when an fd in their set becomes ready.
I think this is also possible for kqueue on bsd, ports on solaris and
IOCP on windows.
Regards,
Daurnimator.
