On Mon, Aug 12, 2013 at 11:41 PM, Tom Lane wrote:
> That sounds like a mess --- race conditions all over the place, even aside
> from efficiency worries.
This I don't understand. All I'm envisioning is setting a flag in the
signal handler. If that flag is set then the next CHECK_FOR_INTERRUPTS
Greg Stark writes:
> So I poked around a bit. It looks like Linux does send a SIGIO when a
> tcp connection is closed (with POLL_HUP if it's closed and POLL_IN if
> it's half-closed). So it should be possible to arrange to get a signal
> which CHECK_FOR_INTERRUPTS could handle the normal way.
> H
On Mon, Aug 12, 2013 at 6:56 PM, Tom Lane wrote:
> Jeff Janes writes:
>> On Sat, Aug 10, 2013 at 4:26 AM, Greg Stark wrote:
>>> The problem is that I don't know of any way to detect eof on a socket
>>> other than trying to read from it (or calling poll or select).
>
>> Do we know how inefficient
Jeff Janes writes:
> On Sat, Aug 10, 2013 at 4:26 AM, Greg Stark wrote:
>> The problem is that I don't know of any way to detect eof on a socket
>> other than trying to read from it (or calling poll or select).
> Do we know how inefficient it is, compared to the baseline work done
> by CHECK_FOR
On Sat, Aug 10, 2013 at 4:26 AM, Greg Stark wrote:
>
> The problem is that I don't know of any way to detect eof on a socket
> other than trying to read from it (or calling poll or select). So the
> server would have to periodically poll the client even when it's not
> expecting any data. The inef
On Sun, Aug 11, 2013 at 9:25 PM, Josh Berkus wrote:
> No, it's been a chronic issue since we got SMP support, pretty much
> forever. Why do you think we have pg_terminate_backend()?
>
> The problem, as explored downthread, is that there's no clear way to fix
> this. It's a problem which goes pre
On 08/10/2013 04:26 AM, Greg Stark wrote:
> On Sat, Aug 10, 2013 at 5:30 AM, Tom Lane wrote:
>> Any other client would behave the same
>> if it were killed while waiting for some backend query. So the right
>> fix would involve figuring out a way for the backend to kill itself
>> if the client co
I think this is utterly the won't way to think about this.
TCP is designed to be robust against transient network outages. They are
*not* supposed to cause disconnections. The purpose of keepalives is to
detect connections that are still valid live connections that are stale and
the remote end is
On Sat, Aug 10, 2013 at 12:26:43PM +0100, Greg Stark wrote:
> On Sat, Aug 10, 2013 at 5:30 AM, Tom Lane wrote:
> > Any other client would behave the same
> > if it were killed while waiting for some backend query. So the right
> > fix would involve figuring out a way for the backend to kill itsel
On Sat, Aug 10, 2013 at 12:30 AM, Tom Lane wrote:
> Tatsuo Ishii writes:
>> I noticed pg_dump does not exit gracefully when killed.
>> start pg_dump
>> kill pg_dump by ctrl-c
>> ps x
>
>> 27246 ?Ds96:02 postgres: t-ishii dbt3 [local] COPY
>> 29920 ?S 0:00 sshd: ishii@pts/
> On Sat, Aug 10, 2013 at 5:30 AM, Tom Lane wrote:
>> Any other client would behave the same
>> if it were killed while waiting for some backend query. So the right
>> fix would involve figuring out a way for the backend to kill itself
>> if the client connection goes away while it's waiting.
I
On Sat, Aug 10, 2013 at 5:30 AM, Tom Lane wrote:
> Any other client would behave the same
> if it were killed while waiting for some backend query. So the right
> fix would involve figuring out a way for the backend to kill itself
> if the client connection goes away while it's waiting.
Well I'm
Tatsuo Ishii writes:
> I noticed pg_dump does not exit gracefully when killed.
> start pg_dump
> kill pg_dump by ctrl-c
> ps x
> 27246 ?Ds96:02 postgres: t-ishii dbt3 [local] COPY
> 29920 ?S 0:00 sshd: ishii@pts/5
> 29921 pts/5Ss 0:00 -bash
> 30172 ?Ss
13 matches
Mail list logo
