Jeff Davis wrote:
> The docs say:
>
> "SIGINT -- The server disallows new connections and sends all existing
> server processes SIGTERM, which will cause them to abort their current
> transactions and exit promptly."
>
> http://www.postgresql.org/docs/8.3/static/server-shutdown.html
>
> If you have an open COPY and no data is moving, it simply won't
> terminate it. You can terminate it with ctrl-C from psql, but not a
> SIGINT to the postmaster or a SIGINT or SIGTERM to the backend.
I actually started to looked at this when you posted, but was pre-empted
with something else. Looking at the code, there's comments that actually
use COPY FROM STDIN as an example of things that should not be
interrupted by signals:
> /*
> * (2) Allow asynchronous signals to be executed immediately if they
> * come in while we are waiting for client input. (This must be
> * conditional since we don't want, say, reads on behalf of COPY FROM
> * STDIN doing the same thing.)
> */
> QueryCancelPending = false; /* forget any earlier CANCEL signal */
> DoingCommandRead = true;
>
> /*
> * (3) read a command (loop blocks here)
> */
> firstchar = ReadCommand(&input_message);
But in light of your bug report, that doesn't seem quite right. We don't
want to enable notify or catchup interrupts during COPY FROM, but we
should react to fast shutdown and query cancel.
I'm not too familiar with this code, but I think we could just enable
ImmediateInterruptOK in CopyGetData().
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com