Re: possible bug not in open items
От | Heikki Linnakangas |
---|---|
Тема | Re: possible bug not in open items |
Дата | |
Msg-id | 49CD2857.8010508@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: possible bug not in open items (Jeff Davis <pgsql@j-davis.com>) |
Ответы |
Re: possible bug not in open items
|
Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления: