Tom Lane wrote:
My apologies for the delayed response.Michael Akinde <michael.akinde@xxxxxx> writes:Anyway - the situation now is that just the loading process is hanging on the server, with an <IDLE> in transaction. But it is definitely the loading program that is hanging, not the Postgres server.What the stack traces seem to show is that both the client and the server are waiting for each other to send some data. Which means somebody's bollixed the protocol. In the past we've seen this type of thing caused by multithreaded client programs in which more than one thread tried to use the same PGconn object without adequate interlocking. libpq itself does not provide any threading guards --- if you want more than one thread accessing a PGconn then it's up to you to use a mutex or something to serialize them. Is it possible this case applies here? Our application is single-threaded, so it seems unlikely that we are running into a problem with that. The only thing I can think of right now, is that we are running a Postgres 8.3 on Debian Etch (so a backported debian package), whereas the libraries linked into our application are older library version (libpq4 and libpqxx 2.6.8). I'll try to upgrade the OS to a version with "native" support for 8.3 and up to date (or at least more up to date) versions of pq, pqxx and check whether the tests still break down. Regards, Michael A. |
begin:vcard fn:Michael Akinde n:Akinde;Michael org:Meteorologisk Institutt, Norge;IT adr;quoted-printable:;;Gaustadall=C3=A9en 30D;Oslo;;0313;Norge email;internet:michael.akinde@xxxxxx tel;work:22963379 tel;cell:45885379 x-mozilla-html:FALSE url:http://www.met.no version:2.1 end:vcard
-- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general