On Mon, December 5, 2005 18:22, Camille Chafer wrote:
>
> Yes and no. The problem go away if I only let the loop.
> But the problem stays here if I drop the t.exec line but keep the
> pqxx::result R declaration.
Then it's not the SQL execution code, which is good news.
But do I understand correctly that your use of the result object is now
merely something like
pqxx::result R;
...and no assignment or use of R after that? The result-related code that
controls this situation is almost completely different. I just walked
through it again and the only thing I can possibly see going wrong is in
template specialization handling for the cleanup function; PQclear() is
called to clean up result sets, whereas free() or an equivalent may be
called for other types of objects.
So the wrong cleanup function might conceivably be called. That's the
only slightly complex or error-prone thing in this code path through
pqxx::result. But in this case, the cleanup function would be called with
a NULL argument! That case should be accepted as a no-op, or if it
wasn't, it would segfault right away.
> I'm using a nontransaction, but also tried pqxx::transaction<> t without
> any difference.
> The libpqxx version is 2.5.5, and i'm compiling using GCC (v 3.4.4) on
> both windows/cygwin and FreeBSD, with -g3 -O0 -Wall compilation options.
> Postgresql version is 8.1.
Hmmm... Another possibility I guess is that something might wrong in
_setting up_ your transaction object. Windows tends to be a bit
problematic as an environment, but the only problems I would normally
expect with libpqxx on FreeBSD are at compile time. On the bright side:
AFAIK postgres is very well-tested on FreeBSD so that pretty much
eliminates another suspect.
Jeroen
_______________________________________________
Libpqxx-general mailing list
[email protected]
http://gborg.postgresql.org/mailman/listinfo/libpqxx-general
