pg.ddx.io pgsql-admin@postgresql.org mailing list archivehelp / color / mirror / Atom feed
postgres doesn't detect other end of the unix socket is gone... 2+ messages / 2 participants [nested] [flat]
* postgres doesn't detect other end of the unix socket is gone... @ 2008-05-07 23:28 Darren Reed <darrenr+postgres@fastmail.net> 0 siblings, 1 reply; 2+ messages in thread From: Darren Reed @ 2008-05-07 23:28 UTC (permalink / raw) To: 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 ^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: postgres doesn't detect other end of the unix socket is gone... @ 2008-05-07 23:46 Scott Marlowe <scott.marlowe@gmail.com> parent: Darren Reed <darrenr+postgres@fastmail.net> 0 siblings, 0 replies; 2+ messages in thread From: Scott Marlowe @ 2008-05-07 23:46 UTC (permalink / raw) To: darrenr@fastmail.net; +Cc: pgsql-admin On Wed, May 7, 2008 at 5:28 PM, Darren Reed <darrenr+postgres@fastmail.net> wrote: > 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. Well, how much time should postgresql spend polling all it's connections to see if they're dead? Generally speaking, it's the client's job to notify the server when it disconnects. > In this case, it would appear that 586 hasn't noticed anything strange > happening. Should it have? Nope, not its job really. > Will this problem go away if I use TCP rather than unix streams? tcp connections use keepalive to harvest such connections. the default setting is 2+hours to notice and drop them. but you can set tcp_keepalive_time to something like 300 (5 minutes) and they'll be harvested much more quickly. > 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? It just never checks. Not a bug really. > Actually, I can see aborting being a bug too...is there a way to > control the behaviour here? Once the OS on the pgsql side notices the disconnect, the standard behaviour is to rollback whatever transaction you're in and exit. ^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2008-05-07 23:46 UTC | newest] Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2008-05-07 23:28 postgres doesn't detect other end of the unix socket is gone... Darren Reed <darrenr+postgres@fastmail.net> 2008-05-07 23:46 ` Scott Marlowe <scott.marlowe@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox