From: | Darren Reed <darrenr+postgres(at)fastmail(dot)net> |
---|---|
To: | "pgsql-admin(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org> |
Subject: | postgres doesn't detect other end of the unix socket is gone... |
Date: | 2008-05-07 23:28:49 |
Message-ID: | 48223B31.4090206@fastmail.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
It would appear that sometimes, when a disconnect a unix stream
(ie perl DBI) from postgres in a forceful manner (^C), postgres
doesn't appear to notice and keeps processing the transaction
rather than aborting it.
As an example, I currently see the following open files:
postgres postgres 28780 7* unix stream c3653d80 <-> c2d6d7c0
postgres postgres 23751 7* unix stream c2aeda80 <-> c3615540
postgres postgres 12631 7* unix stream c35e3640 <-> c2ac1000
postgres postgres 586 7* unix stream c35ce400
postgres postgres 29011 5* unix stream c2adb900
The last two are:
586 ? Ds 0:00.00 postgres: postgres postgres [local] UPDATE
29011 ttyp0- IW 0:00.00 /usr/pkg/bin/postgres -D /home/postgres/db
In this case, it would appear that 586 hasn't noticed anything strange
happening. Should it have?
Will this problem go away if I use TCP rather than unix streams?
Or is this a bug of the variety that when postgres is deep inside
an UPDATE, doing lots of disk I/O, it never checks to see if it
should abort because the client has gone?
Actually, I can see aborting being a bug too...is there a way to
control the behaviour here?
Darren
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Marlowe | 2008-05-07 23:46:39 | Re: postgres doesn't detect other end of the unix socket is gone... |
Previous Message | Kevin Grittner | 2008-05-07 21:29:06 | Re: Can't connect remotely |