Re: Inserting large number of rows using libpq++ stops responding in c++ - Mailing list pgsql-general
From | Taz Master |
---|---|
Subject | Re: Inserting large number of rows using libpq++ stops responding in c++ |
Date | |
Msg-id | 20021202043830.97637.qmail@web12503.mail.yahoo.com Whole thread Raw |
In response to | Re: Inserting large number of rows using libpq++ stops responding in c++ (Tom Lane <tgl@sss.pgh.pa.us>) |
List | pgsql-general |
There is no other client connected to this table at this particular time, though there will be in the future, so that wouldn't be in. Not a possible deadlock condition. I don't see a possbile bug that could cause this. The line that is locking up is the dbdata->ExecCommandOk( query.c_str() ) and for debugging I look at the query before hand and it's fine. What possible program bug could cause ExecCommandOk to not return? Is my series of libpq++ methods okay? #include <string> #include "libpq++.h" class CDBConnect { public: //! Constructor CDBConnect(); CDBConnect( std::string server ); //! Destructor virtual ~CDBConnect(); bool executeSQLcommand( std::string query ); bool commit( ); private: PgTransaction* dbdata; std::string db_server; std::string db_query; }; CDBConnect::CDBConnect( std::string server ) { std::cout << std::endl << "SERVER: " << server << std::endl; db_server = server; dbdata = new PgTransaction(db_server.c_str()); if ( dbdata->ConnectionBad() ) { std::cerr << "Did not connect to server '" << db_server << std::endl; std::cout << "Did not connect to server '" << db_server << std::endl; delete (dbdata); dbdata = NULL; } } // dataserver = "dbname=testserver user=baldur" CDBConnect* DBInventory = new CDBConnect( dataserver ); if ( ! DBInventory->executeSQLcommand( "DELETE FROM playeritems where playerid = " + toString( id ) ) ) { std::cout << "Player: " + name + " in inventory not found to delete. Saveing anyway." << std::endl; } // Now I call many of these. std::string SQLCommand = " INSERT INTO playeritems (" "playerid, linenumber, level, depot, id, wear, number)" "VALUES (" + toString( id ) + ", " + toString( linenumber++ ) + ", 0, false, " + toString( characterItems[ thisItemSlot ].id ) + ", " + toString( characterItems[ thisItemSlot ].wear ) + ", " + toString( characterItems[ thisItemSlot ].number ) + ")"; if ( ! DBInventory->executeSQLcommand( SQLCommand )) { } // And when one of those never returns --- Tom Lane <tgl@sss.pgh.pa.us> wrote: > Taz Master <tazmaster@rocketmail.com> writes: > > My only theory as to what might be causing this would be the large > > number of SQL commands executed before the commit. Is this right? > > No. 100 inserts hardly qualifies as "a large number" -- people > routinely run transactions with many thousand commands. > > I'm guessing a bug in your own code, though it's possible that > libpq++ > is the source of the problem. > > If you have any other clients active at the same time, it's also > possible that there is no bug, and the thing is simply waiting for > a lock held by some other client. This would be more likely if you > have foreign keys in the table being inserted into --- foreign key > references take write-locks on the referenced rows. > > regards, tom lane > > ---------------------------(end of > broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org ===== Taz Master mailto:tazmaster@rocketmail.com __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
pgsql-general by date: