Re: killing pg_dump leaves backend process - Mailing list pgsql-hackers
From | Greg Stark |
---|---|
Subject | Re: killing pg_dump leaves backend process |
Date | |
Msg-id | CAM-w4HP5=EEHtM6-FgV2=mCohYK6RJzgsvSAg7GM20KuNNKwFw@mail.gmail.com Whole thread Raw |
In response to | Re: killing pg_dump leaves backend process (Christopher Browne <cbbrowne@gmail.com>) |
List | pgsql-hackers |
<p dir="ltr">I think this is utterly the won't way to think about this.<p dir="ltr">TCP is designed to be robust againsttransient network outages. They are *not* supposed to cause disconnections. The purpose of keepalives is to detectconnections that are still valid live connections that are stale and the remote end is not longer present for.<p dir="ltr">Keepalivesthat trigger on the timescale of less than several times the msl are just broken and make TCP unreliable.That means they cannot trigger in less than many minutes.<p dir="ltr">This case is one that should just work andshould work immediately. From the users point of view when a client cleanly dies the kernel on the client is fully awareof the connection being closed and the network is working fine. The server should be aware the client has gone away*immediately*. There's no excuse for any polling or timeouts.<br /><br /><p dir="ltr">-- <br /> greg<div class="gmail_quote">On10 Aug 2013 17:30, "Christopher Browne" <<a href="mailto:cbbrowne@gmail.com">cbbrowne@gmail.com</a>>wrote:<br type="attribution" /><blockquote class="gmail_quote"style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On Sat, Aug 10, 2013 at 12:30 AM,Tom Lane <<a href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>> wrote:<br /> > Tatsuo Ishii <<a href="mailto:ishii@postgresql.org">ishii@postgresql.org</a>>writes:<br /> >> I noticed pg_dump does not exit gracefullywhen killed.<br /> >> start pg_dump<br /> >> kill pg_dump by ctrl-c<br /> >> ps x<br /> ><br/> >> 27246 ? Ds 96:02 postgres: t-ishii dbt3 [local] COPY<br /> >> 29920 ? S 0:00sshd: ishii@pts/5<br /> >> 29921 pts/5 Ss 0:00 -bash<br /> >> 30172 ? Ss 0:00 postgres:t-ishii dbt3 [local] LOCK TABLE waiting<br /> ><br /> >> As you can see, after killing pg_dump, a backendprocess is (LOCK<br /> >> TABLE waiting) left behind. I think this could be easily fixed by<br /> >> addingsignal handler to pg_dump so that it catches the signal and<br /> >> issues a query cancel request.<br /> ><br/> > If we think that's a problem (which I'm not convinced of) then pg_dump<br /> > is the wrong place to fixit. Any other client would behave the same<br /> > if it were killed while waiting for some backend query. So theright<br /> > fix would involve figuring out a way for the backend to kill itself<br /> > if the client connectiongoes away while it's waiting.<br /><br /> This seems to me to be quite a bit like the TCP keepalive issue.<br /><br/> We noticed with Slony that if something ungraceful happens in the<br /> networking layer (the specific thing noticedwas someone shutting off<br /> networking, e.g. "/etc/init.d/networking stop" before shutting down<br /> Postgres+Slony),the usual timeouts are really rather excessive, on<br /> the order of a couple hours.<br /><br /> Probablyit would be desirable to reduce the timeout period, so that<br /> the server could figure out that clients are incommunicado"reasonably<br /> quickly." It's conceivable that it would be apropos to diminish the<br /> timeout valuesin postgresql.conf, or at least to recommend that users<br /> consider doing so.<br /> --<br /> When confronted bya difficult problem, solve it by reducing it to the<br /> question, "How would the Lone Ranger handle this?"<br /><br /><br/> --<br /> Sent via pgsql-hackers mailing list (<a href="mailto:pgsql-hackers@postgresql.org">pgsql-hackers@postgresql.org</a>)<br/> To make changes to your subscription:<br/><a href="http://www.postgresql.org/mailpref/pgsql-hackers" target="_blank">http://www.postgresql.org/mailpref/pgsql-hackers</a><br/></blockquote></div>
pgsql-hackers by date: