8.4: COPY continues after client disconnects

[jnelson+ (Jon Nelson)]

Using PostgreSQL 8.4.13 on ScientificLinux 6.3 (x86_64), I noticed
that a pg_dump ran out of (local) disk space.
However, the server was still using CPU and disk resources. An strace
clearly showed this pattern:

read(....) = 8192
sendto(...) = -1 EPIPE
-- SIGPIPE (Broken pipe) @ ....

The server does detect the broken pipe. It logs the following messages:

637 LOG: 08006: could not send data to client: Connection reset by peer
638 LOCATION: internal_flush, pqcomm.c:1108
639 STATEMENT: COPY ... to stdout;
640 LOG: 08006: could not send data to client: Broken pipe
641 LOCATION: internal_flush, pqcomm.c:1108
642 STATEMENT: COPY ... to stdout;


it ran until I killed it.

[Heikki Linnakangas]

Post by jnelson+ (Jon Nelson)
Using PostgreSQL 8.4.13 on ScientificLinux 6.3 (x86_64), I noticed
that a pg_dump ran out of (local) disk space.
However, the server was still using CPU and disk resources. An strace
read(....) = 8192
sendto(...) = -1 EPIPE
637 LOG: 08006: could not send data to client: Connection reset by peer
638 LOCATION: internal_flush, pqcomm.c:1108
639 STATEMENT: COPY ... to stdout;
640 LOG: 08006: could not send data to client: Broken pipe
641 LOCATION: internal_flush, pqcomm.c:1108
642 STATEMENT: COPY ... to stdout;
Cancel the running query if the client gets disconnected (Florian Pflug)
If the backend detects loss of client connection during a query, it will now cancel the query rather than attempting to finish it.

COPY counts as a "running query".