Обсуждение:
pgsql-interface! hello! I have written database interface connnection class library on sybase, oracle .My project has built in the library. Now i will write the same library on postgresql, I need the same interface with oracle, thus Ineedn't modify my project. But i found postgresql interface is limited, for example , many out parameter, can't in a function. and in a function i can't return many record, in libpqxx examples, there is not call function examples. can you help me? 致 礼! cheng ch_gang304@163.net 2002-08-28
I'm having some problems with a multi-threaded application using libpq: Some details: OS: Solaris 2.6 Postgres version 7.2.1 When my application starts up the main thread (1) connects using PQsetdbLogin() which is successful Another thread (5 for example) issues queries over this connection. My test is stopping postgres (KILL -INT) and testing if my application detects the backend failure and tries to re-connect. Thread 5 issues a PQexec and discovers the error upon which thread 5 tries to reconnect (after calling PQfinish) This reconnection HANGS, here is a stack trace: ee037438 poll (ed906e48, 1, ffffffff) ee04cc74 select (ed906e50, ed908ea8, ed908f28, ed908eac, ed908f2c, 4) + 280 ee69e010 pqWait (0, 1, 485e8, 1, 81010100, ee0882cc) + 1d8 ee695178 connectDBComplete (485e8,0, ee0a3180, 0, efffebc0, ee086858) + f8 ee69484c PQsetdbLogin (45e28, ed9091a2, 0, 0, 45d68, 45e40) + 558 All access using the connection is serialized using a mutex. I've tried the same test but with everything running in thread 1 and it works OK. I've managed to spot some differences between the two tests: Multi Threaded test: The re-connect underlying call to connect returns -1 and sets errno to 146 (connection refused) Single Threaded test: The re-connect underlying call to connect returns -1 and errno = 0, so it thinks the connection is "in progress" and tries to complete the connection - but hangs on the select (poll) Any help or ideas greatly appreciated, Joe
Sorry, a typo in my previous message see below.... Joe Murphy wrote: > I'm having some problems with a multi-threaded application using libpq: > > Some details: > OS: Solaris 2.6 > Postgres version 7.2.1 > > When my application starts up the main thread (1) connects using > PQsetdbLogin() which is successful > Another thread (5 for example) issues queries over this connection. > > My test is stopping postgres (KILL -INT) and testing if my application > detects the backend failure and > tries to re-connect. > > Thread 5 issues a PQexec and discovers the error upon which thread 5 > tries to reconnect (after calling PQfinish) > This reconnection HANGS, here is a stack trace: > > ee037438 poll (ed906e48, 1, ffffffff) > ee04cc74 select (ed906e50, ed908ea8, ed908f28, ed908eac, > ed908f2c, 4) + 280 > ee69e010 pqWait (0, 1, 485e8, 1, 81010100, ee0882cc) + 1d8 > ee695178 connectDBComplete (485e8, 0, ee0a3180, 0, efffebc0, > ee086858) + f8 > ee69484c PQsetdbLogin (45e28, ed9091a2, 0, 0, 45d68, 45e40) + 558 > > All access using the connection is serialized using a mutex. > > I've tried the same test but with everything running in thread 1 and it > works OK. > > I've managed to spot some differences between the two tests: > > Multi Threaded test: This should read "Single Threaded Test" > > The re-connect underlying call to connect returns -1 and sets errno to > 146 (connection refused) > > Single Threaded test: This should read Multi Threaded test > > The re-connect underlying call to connect returns -1 and errno = 0, so > it thinks the connection is "in progress" and tries > to complete the connection - but hangs on the select (poll) > > Any help or ideas greatly appreciated, > > Joe > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Joe Murphy - AerSoft Limited 2 Northumberland Avenue, Dun Laoghaire, Co. Dublin. phone: +353-1-2301166 direct: +353-1-2145953 fax: +353-1-2301167 mailto:joe@aersoft.com mobile: +353-86-8526181 http://www.aersoft.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Joe Murphy <joe.murphy@aersoft.ie> writes: >> The re-connect underlying call to connect returns -1 and errno = 0, so >> it thinks the connection is "in progress" and tries >> to complete the connection - but hangs on the select (poll) Well, you have a bug in connect() if it's returning the wrong errno in the multi-thread case. However, our code in fe-connect.c reads like this: if (connect(conn->sock, &conn->raddr.sa, conn->raddr_len) < 0) { if (SOCK_ERRNO == EINTR) /* Interruptedsystem call - we'll just try again */ goto retry1; if (SOCK_ERRNO == EINPROGRESS || SOCK_ERRNO == EWOULDBLOCK || SOCK_ERRNO == 0) { /* * Thisis fine - we're in non-blocking mode, and the * connection is in progress. */ conn->status= CONNECTION_STARTED; } else { /* Something's gone wrong */ connectFailureMessage(conn,SOCK_ERRNO); goto connect_errReturn; } I wonder whether it's really a good idea to treat errno == 0 as indicating "connection in progress". Does anyone know of a platform where zero is actually what is returned in this case? The man pages I can find all say that EINPROGRESS is returned. regards, tom lane
I'm having some problems with a multi-threaded application using libpq: Some details: OS: Solaris 2.6 Postgres version 7.2.1 When my application starts up the main thread (1) connects using PQsetdbLogin() which is successful Another thread (5 for example) issues queries over this connection. My test is stopping postgres (KILL -INT) and testing if my application detects the backend failure and tries to re-connect. Thread 5 issues a PQexec and discovers the error upon which thread 5 tries to reconnect (after calling PQfinish) This reconnection HANGS, here is a stack trace: ee037438 poll (ed906e48, 1, ffffffff) ee04cc74 select (ed906e50, ed908ea8, ed908f28, ed908eac, ed908f2c, 4)+ 280 ee69e010 pqWait (0, 1, 485e8, 1, 81010100, ee0882cc) + 1d8 ee695178 connectDBComplete (485e8, 0, ee0a3180,0, efffebc0, ee086858) + f8 ee69484c PQsetdbLogin (45e28, ed9091a2, 0, 0, 45d68, 45e40) + 558 All access using the connection is serialized using a mutex. I've tried the same test but with everything running in thread 1 and it works OK. I've managed to spot some differences between the two tests: Multi Threaded test: The re-connect underlying call to connect returns -1 and sets errno to 146 (connection refused) Single Threaded test: The re-connect underlying call to connect returns -1 and errno = 0, so it thinks the connection is "in progress" and tries to complete the connection - but hangs on the select (poll) Any help or ideas greatly appreciated, Joe
The problem I was having "went away" when I moved to another Solaris 2.6 machine with the latest patch level. <br />I'vealso tested it on Solaris 8, HP-UX 11.00 and Linux, so it looks like there is a connect bug in a release 2.6, <br />butseems to be fixed with later patches. <p>Thanks for the help. <p>Joe <p>Tom Lane wrote: <blockquote type="CITE">JoeMurphy <joe.murphy@aersoft.ie> writes: <br />>> The re-connect underlying call to connect returns-1 and errno = 0, so <br />>> it thinks the connection is "in progress" and tries <br />>> to completethe connection - but hangs on the select (poll) <p>Well, you have a bug in connect() if it's returning the wrongerrno <br />in the multi-thread case. <p>However, our code in fe-connect.c reads like this: <p> if (connect(conn->sock,&conn->raddr.sa, conn->raddr_len) < 0) <br /> { <br /> if (SOCK_ERRNO == EINTR)<br /> /* Interrupted system call - we'll just try again */ <br /> goto retry1; <p> if(SOCK_ERRNO == EINPROGRESS || SOCK_ERRNO == EWOULDBLOCK || SOCK_ERRNO == 0) <br /> { <br /> /* <br /> * This is fine - we're in non-blocking mode, and the <br /> * connection is in progress. <br /> */ <br /> conn->status = CONNECTION_STARTED; <br /> } <br /> else <br /> { <br /> /* Something's gone wrong */ <br /> connectFailureMessage(conn, SOCK_ERRNO); <br/> goto connect_errReturn; <br /> } <p>I wonder whether it's really a good idea to treat errno == 0as <br />indicating "connection in progress". Does anyone know of a platform <br />where zero is actually what is returnedin this case? The man pages <br />I can find all say that EINPROGRESS is returned. <p> regards,tom lane <p>---------------------------(end of broadcast)--------------------------- <br />TIP 4: Don't 'kill -9'the postmaster</blockquote><pre>-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Joe Murphy - AerSoft Limited 2 Northumberland Avenue, Dun Laoghaire, Co. Dublin. phone: +353-1-2301166 direct: +353-1-2145953 fax: +353-1-2301167 <a href="mailto:joe@aersoft.com">mailto:joe@aersoft.com</a> mobile: +353-86-8526181 <a href="http://www.aersoft.com">http://www.aersoft.com</a> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~</pre>