Jeroen T. Vermeulen | 3 Jun 09:09 2007
Picon
Picon

Site back

Phew.

It looks like our site is back online, and in a way, better than before. 
It took some time for DNS changes to propagate, which is why despite
changes on the server, some queries still ended up on the new
thaiopensource.org server.

>From now on, the libpqxx site is http://pqxx.org/ (or www.pqxx.org if you
prefer).  The thaiopensource.org URLs will no longer work, but on the
bright side, they are also no longer needed.

Jeroen
Jeroen T. Vermeulen | 3 Jun 09:33 2007
Picon
Picon

Re: Using cursor

On Thu, May 31, 2007 14:17, Trigve Siver wrote:

> I mean if there is some diffrence using pqxx Transaction.exec() and
> pqxx::absolute_cursor. AFAIK cursor read results "on demand" while
> Transaction.exec()
> return whole result for executed query. Is it true? Can be there some
> performance gain when using cursors?

Ah, so it's not really about absolute_cursor but about cursors in general.

You understood correctly.  While a cursor only returns chunks of the work,
and only when you ask for them, transaction_base::exec() simply reads the
whole result set at once.

When talking purely about the overall speed it takes to retrieve all your
results, and in a normal program, a cursor will always be slower than
exec().  Don't complicate your code with cursors if you don't need to!

So why do we have cursors at all?  They make sense in many cases:

 * If your result set can be huge, and you only look at one row at a time,
there's no reason to keep the entire result set in memory.  With a cursor
you can download and process just one chunk at a time.

 * If you want to give quick first results, and it takes too long to get
the whole result set, use a cursor to retrieve and process a bit of your
data relatively soon.

 * If you want to give regular progress reports, e.g. a progress bar, on
large result sets, break them up into chunks with a cursor.
(Continue reading)

Curran Schiefelbein | 8 Jun 02:40 2007
Picon

Re: The libpqxx website is unreachable

BTW, link to old site is still given in documentation:
http://pqxx.org/devprojects/libpqxx/doc/2.6.9/html/Reference/
(see bottom of page)

Bart Samwel wrote:
 > Anyway, I suspect that you'll
> have to set a nonnoticer on the connection, something like:
> 
> conn.set_noticer std::auto_ptr<pqxx::noticer> (new pqxx::nonnoticer));

Thanks. I finally (<blush>) got around to trying this... funny thing is, 
I still get the printouts that begin with "+  INSERT INTO..." when the 
code runs.

When the connection object is created, its noticer is null, and then 
after the set_noticer call, the noticer is the NONnoticer I gave it. So 
the auto_ptr stuff should be working.

Actually, if the default value of m_Noticer's contents is null, then 
those "+  INSERT" printouts are definitely not caused by a noticer.

I've been grepping around for the right print statement in both pqxx and 
libpq, but haven't found it yet. Ideas?

--

-- 
Curran Schiefelbein
Bart Samwel | 8 Jun 20:20 2007

Re: The libpqxx website is unreachable

Curran Schiefelbein wrote:
> BTW, link to old site is still given in documentation:
> http://pqxx.org/devprojects/libpqxx/doc/2.6.9/html/Reference/
> (see bottom of page)
> 
> 
> Bart Samwel wrote:
>  > Anyway, I suspect that you'll
>> have to set a nonnoticer on the connection, something like:
>>
>> conn.set_noticer std::auto_ptr<pqxx::noticer> (new pqxx::nonnoticer));
> 
> 
> Thanks. I finally (<blush>) got around to trying this... funny thing is, 
> I still get the printouts that begin with "+  INSERT INTO..." when the 
> code runs.
> 
> When the connection object is created, its noticer is null, and then 
> after the set_noticer call, the noticer is the NONnoticer I gave it. So 
> the auto_ptr stuff should be working.
> 
> Actually, if the default value of m_Noticer's contents is null, then 
> those "+  INSERT" printouts are definitely not caused by a noticer.
> 
> I've been grepping around for the right print statement in both pqxx and 
> libpq, but haven't found it yet. Ideas?

Nope, I'm puzzled! My grepping doesn't yield anything else... Perhaps 
libpq prints this stuff when it runs in some kind of debug mode? 
Otherwise I wouldn't know...
(Continue reading)

Curran Schiefelbein | 8 Jun 23:46 2007
Picon

Re: The libpqxx website is unreachable

Bart Samwel wrote:
> Nope, I'm puzzled! My grepping doesn't yield anything else... Perhaps 
> libpq prints this stuff when it runs in some kind of debug mode? 
> Otherwise I wouldn't know...
> 
> Cheers,
> Bart
> 

It occurs regardless of whether you compile Debug or Release (both 
packages).

It doesn't matter that much. I'm the only one who looks at the output 
(so far). Thanks anyway.

--

-- 
Curran Schiefelbein
Jeroen T. Vermeulen | 9 Jun 15:45 2007
Picon
Picon

Re: The libpqxx website is unreachable

On Sat, June 9, 2007 04:46, Curran Schiefelbein wrote:
> Bart Samwel wrote:
>> Nope, I'm puzzled! My grepping doesn't yield anything else... Perhaps
>> libpq prints this stuff when it runs in some kind of debug mode?
>> Otherwise I wouldn't know...

> It occurs regardless of whether you compile Debug or Release (both
> packages).

There's no printing of anything in libpqxx, but libpq has two output
channels that I know of:

1. The noticer, which should shut up when it's the nonnoticer.  Could
always be a bug there...  Lifetime management problem maybe?

2. Trace output.  Unless you call the connection's trace() function, that
shouldn't happen.  And it spews a lot more than just a few statements.

Jeroen
Jeroen T. Vermeulen | 9 Jun 15:46 2007
Picon
Picon

Re: The libpqxx website is unreachable

On Sat, June 9, 2007 04:46, Curran Schiefelbein wrote:
> Bart Samwel wrote:
>> Nope, I'm puzzled! My grepping doesn't yield anything else... Perhaps
>> libpq prints this stuff when it runs in some kind of debug mode?
>> Otherwise I wouldn't know...

> It occurs regardless of whether you compile Debug or Release (both
> packages).

There's no printing of anything in libpqxx, but libpq has two output
channels that I know of:

1. The noticer, which should shut up when it's the nonnoticer.  Could
always be a bug there...  Lifetime management problem maybe?

2. Trace output.  Unless you call the connection's trace() function, that
shouldn't happen.  And it spews a lot more than just a few statements.

Jeroen
Gary Jefferson | 12 Jun 21:09 2007
Picon

forcing reconnect

there doesn't seem to be a 'reconnect()' in
pqxx::connection_base.  What is the best way to
explicitly force connections to reconnect (as in the
case where the db has failed over to a slave, and dns
has been updated to make the slave the new master)?  

Gary

       
____________________________________________________________________________________
Choose the right car based on your needs.  Check out Yahoo! Autos new Car Finder tool.
http://autos.yahoo.com/carfinder/
Jan Danielsson | 14 Jun 07:13 2007
Picon

prepared statements crash libpqxx 2.6.9


Hello,

   The following program crashes when I run it (I have marked where):

-------------------------------------------
#include <iostream>
#include <string>
#include <pqxx/pqxx>

class ServerContext
{
	private:
	pqxx::connection m_conn;

	public:
	ServerContext();

	bool createSession();
	bool touchSession(const std::string& id);
};

ServerContext::ServerContext() : m_conn("")
{
	std::cout << "Foo 1" << std::endl;
	m_conn.prepare("addsess", "INSERT INTO sessions (id,addr) VALUES \
($1,$2)");

	std::cout << "Foo 2" << std::endl;
	m_conn.prepare("touchsess", "UPDATE sessions WHERE id=$1 SET \
(Continue reading)

Bart Samwel | 16 Jun 19:07 2007

Re: prepared statements crash libpqxx 2.6.9

Hi Jan,

Could you try the latest SVN version of libpqxx? I remember that 
something was fixed in this region recently, and I'm not sure if that 
fix is in 2.6.9.

Cheers,
Bart

Jan Danielsson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> Hello,
> 
>    The following program crashes when I run it (I have marked where):
> 
> - -------------------------------------------
> #include <iostream>
> #include <string>
> #include <pqxx/pqxx>
> 
> 
> class ServerContext
> {
> 	private:
> 	pqxx::connection m_conn;
> 
> 	public:
> 	ServerContext();
(Continue reading)


Gmane