From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
---|---|
To: | Jon Nelson <jnelson+pgsql(at)jamponi(dot)net> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: 8.4: COPY continues after client disconnects |
Date: | 2013-03-08 11:04:32 |
Message-ID: | 5139C5C0.5070305@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
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 attempting to finish it.
COPY counts as a "running query".
--
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | mv.gonzalez | 2013-03-08 11:38:03 | BUG #7924: Trigger update function don't take correct values |
Previous Message | Pavel Stehule | 2013-03-08 09:23:29 | Re: [BUGS] BUG #7873: pg_restore --clean tries to drop tables that don't exist |