Re: Cancelling Requests Frontend/Backend Protocol TCP/IP - Mailing list pgsql-general

From Raimon Fernandez
Subject Re: Cancelling Requests Frontend/Backend Protocol TCP/IP
Date
Msg-id 3A922FE6-B9F9-4A8E-BBEA-102CB29AC2B1@montx.com
Whole thread Raw
In response to Re: Cancelling Requests Frontend/Backend Protocol TCP/IP  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Cancelling Requests Frontend/Backend Protocol TCP/IP  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
On 02/11/2009, at 17:35, Tom Lane wrote:

> Raimon Fernandez <coder@montx.com> writes:
>> Quoted from the documentation:
>> "The cancellation signal might or might not have any effect — for
>> example, if it arrives after the
>> backend has finished processing the query, then it will have no
>> effect.
>
>> Here I understand that maybe it will have NO effect, so postgresql
>> will still sending rows and rows and rows ...
>
> If you're too late, the backend has already sent all the rows.
> There's
> not much we can do about data that's already in flight.  There
> probably
> won't be that much of it though, as TCP stacks don't buffer infinite
> amounts of data.

The sentence 'backend has finished processing the query' means that
postgresql has finished processing the select and also has sent all
the rows ?

I thought it meant only processing the request, and the rows were not
yet sent all of them.

If the rows have been sent, and there are data in the TCP buffer,
that's another story ...

thanks,

raimon

pgsql-general by date:

Previous
From: Craig Ringer
Date:
Subject: Re: Cancelling Requests Frontend/Backend Protocol TCP/IP
Next
From: Tom Lane
Date:
Subject: Re: Cancelling Requests Frontend/Backend Protocol TCP/IP