Re: PQstatus() detect change in connection... - Mailing list pgsql-hackers

From Matthew Hagerty
Subject Re: PQstatus() detect change in connection...
Date
Msg-id 5.1.0.14.2.20011018001654.01d49128@pop.voyager.net
Whole thread Raw
In response to Re: PQstatus() detect change in connection...  ("Mark Pritchard" <mark@tangent.net.au>)
Responses Re: PQstatus() detect change in connection...
Re: PQstatus() detect change in connection...
List pgsql-hackers
I am trying to re-establish a connection, however, I cannot afford to issue 
a query to determine if the connection still exists.  I'm writing a server 
that uses the asynchronous query processing functions and speed is an 
issue.  Queries are slow compared to what the server does and it cannot 
wait around for a query to finish just to see if another query *should* be 
attempted based on the connection status.

I've been digging into the libpq code to see what is going on, maybe I can 
gleam a little hint or two  there...  Anyone know a good *fast* way to test 
if a socket is still valid?

Thanks,
Matthew

At 11:51 AM 10/18/2001 +1000, Mark Pritchard wrote:
>I presume you are trying to re-establish a connection automatically...if
>that doesn't apply, ignore the rest of this email :)
>
>The way I interpreted the docs was that you can use the return codes from
>PQexec() to establish whether the command was sent to the backend correctly.
>PQresultStatus() returns whether the command was syntactically
>correct/executed OK.
>
>I've attached a chunk of code from a back-end independent DB driver
>(supports Oracle, PgSQL, MySQL through the same front end API), which
>implements this auto-reconnect. Take a look at the sqlExec() method.
>
>This code successfully recovers when used in a client connection pool in the
>following sequence:
>
>1) start postmaster
>2) connect through pool/driver
>3) issue SQL statements
>4) kill postmaster
>5) start postmaster
>6) issue SQL statements
>7) driver detects connection invalid, reconnects and re-issues
>automatically.
>
>Perhaps those infinitely more knowledgeable on the list have a better/more
>correct way of doing things?
>
>Cheers,
>
>Mark Pritchard
>
> > -----Original Message-----
> > From: pgsql-hackers-owner@postgresql.org
> > [mailto:pgsql-hackers-owner@postgresql.org]On Behalf Of Matthew Hagerty
> > Sent: Thursday, 18 October 2001 10:47 AM
> > To: pgsql-hackers@postgresql.org
> > Subject: [HACKERS] PQstatus() detect change in connection...
> >
> >
> > Greetings,
> >
> > PostgreSQL 7.1.3, FreeBSD-4.3-RELEASE, gcc 2.95.3
> >
> > I'm trying to attempt to detect a failed backend connection, but
> > a call to
> > PQstatus() always returns the state of the backend when the call was
> > made.  For example, take this test code:
> >
> >       PGconn *pgConn;
> >       PGresult *pgRes;
> >       int fdPGconn;
> >
> >       int i = 0;
> >       int iNewState = 0;
> >       int iOldState = 60;
> >
> >       pgConn = PQconnectdb("dbname=pglogd user=postgres");
> >
> >       while ( i == 0 )
> >       {
> >               iNewState = PQstatus(pgConn);
> >
> >               if ( iNewState != iOldState )
> >               {
> >                       iOldState = iNewState;
> >                       printf("Connection State [%d]\n", iNewState);
> >
> >                       fdPGconn = PQsocket(pgConn);
> >                       printf("Connection Socket [%d]\n", fdPGconn);
> >               }
> >
> >               sleep(1);
> >       }
> >
> >       PQfinish(pgConn);
> >
> > If you start this with the backend running, the status is CONNECTION_OK,
> > then pull the plug on the backend, the call to PQstatus() will
> > still return
> > CONNECTION_OK, even though the backend is not running.  Start
> > this program
> > with the backend not running, then start the backend, PQstatus()
> > never sees
> > the backend come to life...
> >
> > Am I reading PQstatus() wrong?  Is there any way to detect when
> > the backend
> > goes down or comes back up?
> >
> > Thanks,
> > Matthew
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 2: you can get off all lists at once with the unregister command
> >     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
> >
>



pgsql-hackers by date:

Previous
From: Bill Studenmund
Date:
Subject: Re: schema support, was Package support for Postgres
Next
From: Lee Kindness
Date:
Subject: Re: compiling libpq++ on Solaris with Sun SPRO6U2 (fixed