Jeroen T. Vermeulen escribió:
> On Thu, November 30, 2006 03:31, Tomasz Myrta wrote:
>
>> I used keepalive the same way as you (reconfiguring socket directly) and
>> I don't remember libpq trying to reconnect itself. I think it's a
>> libpqxx's behaviour - I didn't use it, but it looks like it is called
>> "reactivation".
>
> That's right. It's libpqxx, not libpq, that restores the connection. (It
> couldn't really be any other way because libpq doesn't have enough
> information to know it's safe--you could be in the middle of a
> transaction, or you could be losing a temp table). Automatic reactivation
> can also be disabled explicitly if you don't want it (or just *when* you
> don't want it--e.g. when you're working with temp tables).
>
> I do think that the long TCP timeouts are something that should be handled
> at the lower levels. We can't really do real keepalives, I guess, simply
> because libpq is synchronous to the application. But perhaps we could
> demand that the server at least acknowledge a request in some way within a
> particular time limit? It'd have to be at the lowest level possible and
> as "cheap" as possible, so it doesn't break when the server is merely very
> busy.
Thanks all for your responses, but this is *not* a libpqxx issue, just
because I'm doing the test using plain libpq. Anyways, I have a little
more information about my problem and it's no libpq either =)
The problem is shown when the time between the wire is unplugged and the
use of the connection is not long enough to let the keep-alive kill the
connection. Then the connection becomes active and the TCP timers looks
like go back to the defaults, because there is data in the socket queue
to send. So it's an OS/TCP issue.
I don't see any way to control this without using an application-level
keep-alive, so I appreciate any ideas and suggestions =)
--
Leandro Lucarella
Integratech S.A.
4571-5252
