On Sat, Aug 10, 2013 at 4:26 AM, Greg Stark st...@mit.edu 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.
Jeff Janes jeff.ja...@gmail.com writes:
On Sat, Aug 10, 2013 at 4:26 AM, Greg Stark st...@mit.edu 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
On Mon, Aug 12, 2013 at 6:56 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Jeff Janes jeff.ja...@gmail.com writes:
On Sat, Aug 10, 2013 at 4:26 AM, Greg Stark st...@mit.edu 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
Greg Stark st...@mit.edu 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
On Mon, Aug 12, 2013 at 11:41 PM, Tom Lane t...@sss.pgh.pa.us 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
On 08/10/2013 04:26 AM, Greg Stark wrote:
On Sat, Aug 10, 2013 at 5:30 AM, Tom Lane t...@sss.pgh.pa.us 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
On Sun, Aug 11, 2013 at 9:25 PM, Josh Berkus j...@agliodbs.com 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
On Sat, Aug 10, 2013 at 5:30 AM, Tom Lane t...@sss.pgh.pa.us 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
On Sat, Aug 10, 2013 at 5:30 AM, Tom Lane t...@sss.pgh.pa.us 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
On Sat, Aug 10, 2013 at 12:30 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Tatsuo Ishii is...@postgresql.org 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
On Sat, Aug 10, 2013 at 12:26:43PM +0100, Greg Stark wrote:
On Sat, Aug 10, 2013 at 5:30 AM, Tom Lane t...@sss.pgh.pa.us 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
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
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 0:00 postgres: t-ishii dbt3
Tatsuo Ishii is...@postgresql.org 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
14 matches
Mail list logo
