Thomas Seifert <TS77@gmx.de> writes:
> #0 0x400252ef in resetPQExpBuffer () from /usr/local/pgsql/lib/libpq.so.2
> #1 0x4002537d in printfPQExpBuffer () from /usr/local/pgsql/lib/libpq.so.2
> #2 0x400213e7 in PQgetResult () from /usr/local/pgsql/lib/libpq.so.2
> #3 0x40021467 in PQexec () from /usr/local/pgsql/lib/libpq.so.2
> #4 0x80eafa3 in _rollback_transactions (rsrc=0x8378268) at pgsql.c:168
> #5 0x8146ee4 in zend_hash_apply (ht=0x82c0ad4,
> apply_func=0x80eaf80 <_rollback_transactions>) at zend_hash.c:692
> #6 0x80eb140 in php_rshutdown_pgsql (type=1, module_number=20) at pgsql.c:246
Hm. As best I can tell, the only way that that path of control could
occur is if conn->asyncStatus contains an invalid value. Since
resetPQExpBuffer is also seemingly dying because of an invalid value
in the PGconn record, my bet is that _rollback_transactions is passing
an invalid PGconn (perhaps one that's already been freed?) to PQexec.
At this point I think you need an Apache/PHP/Zend expert, not a Postgres
expert ...
regards, tom lane