Re: ECPG Segfaulting on EXEC SQL connect - Mailing list pgsql-general

From John Smith
Subject Re: ECPG Segfaulting on EXEC SQL connect
Date
Msg-id 200501012335.j01NZgXi000904@romana.roundel.net
Whole thread Raw
In response to Re: ECPG Segfaulting on EXEC SQL connect  (Michael Meskes <meskes@postgresql.org>)
List pgsql-general
Hi Michael,

I'll try and get a nice small pared-down source for you to play with that
demonstrates the problem. Once I get that, I could certainly try rc3,
although I was hoping to wait for the RPM...

John.

-----Original Message-----
From: Michael Meskes [mailto:meskes@postgresql.org]
Sent: 01 January 2005 15:08
To: John Smith
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] ECPG Segfaulting on EXEC SQL connect

On Tue, Dec 28, 2004 at 10:16:04PM -0000, John Smith wrote:
> I'm trying to convert a series of C programs written originally using
> Informix ESQL to use Postgres' ECPG.
> ...
> 575             EXEC SQL connect to pdev_changename;
> ...
> I'm using Postgres 8.0.0rc1 on Redhat 9 (kernel 2.4.20-31.9). The same
> thing happens on fedora core 3, and using Postgres 7.4.6-1.FC3-1.

Could you please try rc3? I did fix some segfaults in the connect statement.
However, I'm not sure you hit the same bug, actually I expect it to be a
different one.

> The ability to define variables of type "timestamp" etc. is so useful,
> so I really want to keep using "-C INFORMIX" if I can.

You can use the datatypes without informix mode. You just have to include
the pgtypes_*.h header files yourself.

> Can anyone help shed any light on this?

I will try if you could send me an example to reproduce the problem. As you
said it does not happen on a small self written test case. Maybe you can
send me one of your source files stripped down to just connect.

Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org Go SF
49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!



pgsql-general by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: Large Objects
Next
From: peter pilsl
Date:
Subject: many similar indexbased selects are extremely slow