From: | Fujii Masao <fujii(dot)masao(at)oss(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #2576: tcp_keepalive doesn't work |
Date: | 2006-08-21 07:27:15 |
Message-ID: | 44E96053.10200@oss.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Tom Lane wrote:
> According to that, Linux keepalive starts working once you have either
> sent or received at least one byte over the connection. Therefore it's
> not possible to get past the authentication stage without keepalive
> being ready to go. And we do have a pretty short timeout on the auth
> stage (1 minute if memory serves).
Do you mean authentication_timeout?
It's useless in my example because 'idle in transaction' backends
have already gotten past the auth stage.
> So I'm not seeing what problem we
> need to solve.
Please consider the system that puts the load from
two AP servers to one DB server.
At this time, the problem is that the processing of overall DB server might stop
when the LAN cable of only one AP server comes off.
Because 'idle in transaction' backends that don't terminate by tcp_keepalive
keep holding the lock.
>
> In any case, if you don't like that behavior methinks you need to be
> lobbying some kernel hackers, not database weenies. Postgres is not
> in the business of second-guessing the TCP stack.
ok.
I also think that solving at the Kernel level is the best in this problem.
best regards;
From | Date | Subject | |
---|---|---|---|
Next Message | Sunil Kumar Basu | 2006-08-21 13:26:14 | BUG #2586: Connecting problem |
Previous Message | Taiki Yamaguchi | 2006-08-21 02:00:45 | boolean type cast |