Up to now large swathes of backend code ran inside signal handlers while reading commands from the client, to allow for speedy reaction to asynchronous events. Most prominently shared invalidation and NOTIFY handling. That means that complex code like the starting/stopping of transactions is run in signal handlers... The required code was fragile and verbose, and is likely to contain bugs. That approach also severely limited what could be done while communicating with the client. As the read might be from within openssl it wasn't safely possible to trigger an error, e.g. to cancel a backend in idle-in-transaction state. We did that in some cases, namely fatal errors, nonetheless. Now that FE/BE communication in the backend employs non-blocking sockets and latches to block, we can quite simply interrupt reads from signal handlers by setting the latch. That allows us to signal an interrupted read, which is supposed to be retried after returning from within the ssl library. As signal handlers now only need to set the latch to guarantee timely interrupt processing, remove a fair amount of complicated & fragile code from async.c and sinval.c. We could now actually start to process some kinds of interrupts, like sinval ones, more often that before, but that seems better done separately. This work will hopefully allow to handle cases like being blocked by sending data, interrupting idle transactions and similar to be implemented without too much effort. In addition to allowing getting rid of ImmediateInterruptOK, that is. Author: Andres Freund Reviewed-By: Heikki Linnakangas |
||
---|---|---|
.. | ||
Makefile | ||
README.SSL | ||
auth.c | ||
be-fsstubs.c | ||
be-secure-openssl.c | ||
be-secure.c | ||
crypt.c | ||
hba.c | ||
ip.c | ||
md5.c | ||
pg_hba.conf.sample | ||
pg_ident.conf.sample | ||
pqcomm.c | ||
pqformat.c | ||
pqmq.c | ||
pqsignal.c |
README.SSL
src/backend/libpq/README.SSL SSL === >From the servers perspective: Receives StartupPacket | | (Is SSL_NEGOTIATE_CODE?) ----------- Normal startup | No | | Yes | | (Server compiled with USE_SSL?) ------- Send 'N' | No | | | | Yes Normal startup | | Send 'S' | | Establish SSL | | Normal startup >From the clients perspective (v6.6 client _with_ SSL): Connect | | Send packet with SSL_NEGOTIATE_CODE | | Receive single char ------- 'S' -------- Establish SSL | | | '<else>' | | Normal startup | | Is it 'E' for error ------------------- Retry connection | Yes without SSL | No | Is it 'N' for normal ------------------- Normal startup | Yes | Fail with unknown ---------------------------------------------------------------------------