From: | Matthew Hagerty <mhagerty(at)voyager(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Mark Pritchard" <mark(at)tangent(dot)net(dot)au>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: PQstatus() detect change in connection... |
Date: | 2001-10-18 20:54:57 |
Message-ID: | 5.1.0.14.2.20011018164554.01c6fe68@pop.voyager.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At 02:10 PM 10/18/2001 -0400, Tom Lane wrote:
>Matthew Hagerty <mhagerty(at)voyager(dot)net> writes:
> > Anyone know a good *fast* way to test
> > if a socket is still valid?
>
>What exactly are you trying to defend against?
>
>In general, I don't believe that there is any way of discovering whether
>the server is still up, other than to send it a query. (FWIW, an empty
>query string bounces back very quickly, with little processing.)
>
>For particular scenarios it's possible that some notification has been
>delivered to the client, but if you have had (say) a loss of network
>connectivity then there just is no other alternative. Your end isn't
>going to discover the connectivity loss until it tries to send a
>message.
>
> regards, tom lane
I was using PQstatus() under the assumption that it actually *checked* the
connection, however I have since discovered that is simply returns the
value in a structure, and that value only gets updated in pqReadData() or
pqReadReady() (both of which are internal function calls.)
What I'm doing is using the asynchronous processing to write a server that
does not have to wait around for a query to finish (which is a slow process
compared to what the rest of the server does.) So, using a query to test
if the connection is up seems rather redundant and slow... I was hoping to
come up with a faster more simple solution. If the connection is down I
need to write - what would have been a query - to a temporary place and
attempt a reconnect, all while going off and doing other things.
This all came about when my main select() bailed because the backend went
down and the socket's file-descriptor became invalid. I could probably
catch the error in that loop, but I also want to check the connection
*before* submitting a query... Basically, I hope to avoid a huge rewrite
based on my assumption of how PQstatus() was actually working. ;-)
Currently I'm looking at fnctl() or a dedicated select() call (similar to
what pgReadReady() does), but I'm not sure of the OS overhead of these
solutions compared to each other or an empty query. Any insight would be
greatly appreciated.
Thanks,
Matthew
From | Date | Subject | |
---|---|---|---|
Next Message | Philip Hallstrom | 2001-10-18 21:02:22 | Re: To Postgres Devs : Wouldn't changing the select limit |
Previous Message | David Ford | 2001-10-18 20:23:04 | Re: To Postgres Devs : Wouldn't changing the select limit |