Обсуждение: 8.4: COPY continues after client disconnects

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.


--
Jon

On 01.03.2013 17:15, Jon Nelson wrote:
> 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;

This was fixed in version 9.2. Per release notes:

>     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
attemptingto finish it. 

COPY counts as a "running query".

--
- Heikki