C function fails afeter create extension but ok after reconnect

Started by Stephen Woodbridgealmost 13 years ago2 messagesgeneral
Jump to latest
#1Stephen Woodbridge
imaptools@gmail.com

Hi all,

I have a C function that works fine in all cases except if I try to run
it after create extension without reconnecting to the database.

So this fails:

createdb -U postgres -h localhost ttt
psql -U postgres -h localhost ttt
create extension postgis;
create extension pgrouting;
-- create some data
select cost, count(*) from (
select * from pgr_drivingdistance('select id, source, target,
1.0::float8 as cost from ddnoded2', 1274, 10, false, false)
) as foo group by cost order by cost asc;

-- fails with a bad-alloc in boost

\c ttt

select cost, count(*) from (
select * from pgr_drivingdistance('select id, source, target,
1.0::float8 as cost from ddnoded2', 1274, 10, false, false)
) as foo group by cost order by cost asc;

-- run to successful conclusion

Also if a reconnect after the create extension command everything is ok.

Anyone know why this is and how I can fix it ot what to look for in my code?

Thanks,
-Steve

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Stephen Woodbridge (#1)
Re: C function fails afeter create extension but ok after reconnect

Stephen Woodbridge <imaptools@gmail.com> writes:

I have a C function that works fine in all cases except if I try to run
it after create extension without reconnecting to the database.

There's not nearly enough info here to diagnose the problem, but
if I had to bet I'd bet on a memory-management bug that just
accidentally fails to fail in the freshly-reconnected case.

The first thing you should do, if you didn't already, is to build
the backend with --enable-cassert to turn on assorted memory allocation
checks. That might make the bug happen consistently, which would be
a good thing. After that, I'd try capturing a stack trace from the
point of the error report, in hopes of narrowing down what code is
causing the problem.

regards, tom lane

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general