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

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Reply via email to