libopendbx-devel — Help and discussion about OpenDBX

Re: [opendbx] Building errors opendbx 1.4.5

[Miguel S. <mik...@gm...>]

Hi Mariano,

On Norberts suggestion I'm cutting over to try with the DBXObcPlatform
but I'm still getting a fatal error on odbx_bind.

I was wondering, if I'm using DBXOdbcPlatform won't I need to give it
a DSN rather than a host name?  Are there any special instructions for
configuring DBXConnectionSettings on an ODBC connection?

Regards,


Miguel

On 18 March 2011 21:55, Mariano Martinez Peck <mar...@gm...> wrote:
> Hi Miguel, what happens if you try with 1.5.0 ??
>
> As far as I can see in 1.4.5, odbxlib.c    at the end there is a big if:
>
> #ifdef HAVE_WINDOWS_H
> #include <windows.h>
> #endif
>
>
> static int _odbx_lib_register( struct odbx_t* handle, const char* library )
>
> -......
>
>
> #else
> #error "Building shared libraries requires capabilities to load libraries
> dynamically"
> #endif
>
>
> I have no idea.....Norbert will probably help you.
>
> Cheers
>
> Mariano
>
>
>
> On Fri, Mar 18, 2011 at 12:10 PM, Miguel Sanchez <mik...@gm...>
> wrote:
>>
>> Hi All,
>>
>> I'm trying to make opendbx-1.4.5 under MingW on Win XP SP3. I get the
>> following error on make .
>> (Despite this error I can see it has built
>> ./backends/mssql/.libs/libmssqlbackend-1.dll). I presume what is not
>> being built is libopendbx?
>> .
>> .
>> .
>> libtool: compile:  gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I..
>> -DLIBVERSION=10405 -D
>> LOCALEDIR=\"/usr/local/share/locale\" -DLIBPATH=\"/usr/local/lib/opendbx\"
>> -DLIB
>> PREFIX=\"lib\" -DLIBSUFFIX=\"-1.dll\" -Ic:/mingw/msys/1.0/local/include -g
>> -O2 -
>> MT libopendbx_la-odbxlib.lo -MD -MP -MF .deps/libopendbx_la-odbxlib.Tpo -c
>> odbxl
>> ib.c  -DDLL_EXPORT -DPIC -o .libs/libopendbx_la-odbxlib.o
>> odbxlib.c:259:2: error: #error "Building shared libraries requires
>> capabilities
>> to load libraries dynamically"
>> make[2]: *** [libopendbx_la-odbxlib.lo] Error 1
>> make[2]: Leaving directory `/opendbx/lib'
>> make[1]: *** [all-recursive] Error 1
>> make[1]: Leaving directory `/opendbx'
>> make: *** [all] Error 2
>>
>> My configuration  was as follows.
>>
>> $ CPPFLAGS="-Ic:/mingw/msys/1.0/local/include"
>> LDFLAGS="-Lc:/mingw/msys/1.0/loc
>> al/lib" configure --disable-utils --with-backends="mssql"
>>
>>
>> Best Regards,
>>
>>
>> Miguel
>>
>>
>> ------------------------------------------------------------------------------
>> Colocation vs. Managed Hosting
>> A question and answer guide to determining the best fit
>> for your organization - today and in the future.
>> http://p.sf.net/sfu/internap-sfd2d
>> _______________________________________________
>> libopendbx-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/libopendbx-devel
>> http://www.linuxnetworks.de/doc/index.php/OpenDBX
>
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> libopendbx-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libopendbx-devel
> http://www.linuxnetworks.de/doc/index.php/OpenDBX
>
>

Re: [opendbx] Future plans

[Norbert S. <no...@li...>]

Hi Benoit

> Are there any plans to support DB/2 in the near future ?

Due to my lack of time I can't do it myself at the moment. Despite this, 
I would be very happy if someone would start implementing a DB2 backend 
and I am willing to give as much support as I can.


Norbert

Re: [opendbx] Future plans

[Mariano M. P. <mar...@gm...>]

On Mon, Mar 21, 2011 at 1:17 AM, Benoit St-Jean <bs...@ya...> wrote:

> Hello everyone,
>
> Are there any plans to support DB/2 in the near future ?
>
>
Yes. At least it is written here:
http://www.linuxnetworks.de/doc/index.php/OpenDBX/Future
Nevertheless, I wouldn't expect too much. I am not sure Norbert has time
enough.

The good thing is that OpenDBX has a good design and even being C it is easy
to extend :)
If you see you have all the OpenDBX "core" in the files that are in /lib
and then, for each backend there is a "BACKEND_basic.c"   in /backends.  So
it is a matter of writing a db2.basic.c
where you map the openDBX functions to DB2 client library functions.

Ok...all that is just my thought and been a C newbie. So probably it is much
more complicated than that hehehhe

Cheers

Mariano


> Thank you.
>
> -----------------
> Benoit St-Jean
> Yahoo! Messenger: bstjean
> A standpoint is an intellectual horizon of radius zero.
> (Albert Einstein)
>
>
>
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> libopendbx-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libopendbx-devel
> http://www.linuxnetworks.de/doc/index.php/OpenDBX
>
>

[opendbx] Future plans

[Benoit St-J. <bs...@ya...>]

Hello everyone,

Are there any plans to support DB/2 in the near future ?

Thank you.

 -----------------
Benoit St-Jean
Yahoo! Messenger: bstjean
A standpoint is an intellectual horizon of radius zero.
(Albert Einstein)

Re: [opendbx] Building errors opendbx 1.4.5

[Norbert S. <no...@li...>]

Hi Miguel

> I'm trying to make opendbx-1.4.5 under MingW on Win XP SP3. I get the
> following error on make .
> (Despite this error I can see it has built
> ./backends/mssql/.libs/libmssqlbackend-1.dll). I presume what is not
> being built is libopendbx?
> .
> odbxlib.c:259:2: error: #error "Building shared libraries requires capabilities
> to load libraries dynamically"

This is a little bit strange as it means that the WIN32 platform isn't 
recognized. Could you please send me your config.log file?

> My configuration  was as follows.
>
> $ CPPFLAGS="-Ic:/mingw/msys/1.0/local/include" LDFLAGS="-Lc:/mingw/msys/1.0/loc
> al/lib" configure --disable-utils --with-backends="mssql"

Besides from this error I would recommend you to use the ODBC backend on 
Win32 platforms as this is the native method supported by MS SQL Server. 
The "mssql" backend is mainly for Unix-like systems that have to use 
FreeTDS.


Norbert

Re: [opendbx] Building errors opendbx 1.4.5

[Mariano M. P. <mar...@gm...>]

Hi Miguel, what happens if you try with 1.5.0 ??

As far as I can see in 1.4.5, odbxlib.c    at the end there is a big if:

#ifdef HAVE_WINDOWS_H
#include <windows.h>
#endif


static int _odbx_lib_register( struct odbx_t* handle, const char* library )

-......


#else
#error "Building shared libraries requires capabilities to load libraries
dynamically"
#endif


I have no idea.....Norbert will probably help you.

Cheers

Mariano



On Fri, Mar 18, 2011 at 12:10 PM, Miguel Sanchez <mik...@gm...>wrote:

> Hi All,
>
> I'm trying to make opendbx-1.4.5 under MingW on Win XP SP3. I get the
> following error on make .
> (Despite this error I can see it has built
> ./backends/mssql/.libs/libmssqlbackend-1.dll). I presume what is not
> being built is libopendbx?
> .
> .
> .
> libtool: compile:  gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I..
> -DLIBVERSION=10405 -D
> LOCALEDIR=\"/usr/local/share/locale\" -DLIBPATH=\"/usr/local/lib/opendbx\"
> -DLIB
> PREFIX=\"lib\" -DLIBSUFFIX=\"-1.dll\" -Ic:/mingw/msys/1.0/local/include -g
> -O2 -
> MT libopendbx_la-odbxlib.lo -MD -MP -MF .deps/libopendbx_la-odbxlib.Tpo -c
> odbxl
> ib.c  -DDLL_EXPORT -DPIC -o .libs/libopendbx_la-odbxlib.o
> odbxlib.c:259:2: error: #error "Building shared libraries requires
> capabilities
> to load libraries dynamically"
> make[2]: *** [libopendbx_la-odbxlib.lo] Error 1
> make[2]: Leaving directory `/opendbx/lib'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/opendbx'
> make: *** [all] Error 2
>
> My configuration  was as follows.
>
> $ CPPFLAGS="-Ic:/mingw/msys/1.0/local/include"
> LDFLAGS="-Lc:/mingw/msys/1.0/loc
> al/lib" configure --disable-utils --with-backends="mssql"
>
>
> Best Regards,
>
>
> Miguel
>
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> libopendbx-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libopendbx-devel
> http://www.linuxnetworks.de/doc/index.php/OpenDBX
>

[opendbx] Building errors opendbx 1.4.5

[Miguel S. <mik...@gm...>]

Hi All,

I'm trying to make opendbx-1.4.5 under MingW on Win XP SP3. I get the
following error on make .
(Despite this error I can see it has built
./backends/mssql/.libs/libmssqlbackend-1.dll). I presume what is not
being built is libopendbx?
.
.
.
libtool: compile:  gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -DLIBVERSION=10405 -D
LOCALEDIR=\"/usr/local/share/locale\" -DLIBPATH=\"/usr/local/lib/opendbx\" -DLIB
PREFIX=\"lib\" -DLIBSUFFIX=\"-1.dll\" -Ic:/mingw/msys/1.0/local/include -g -O2 -
MT libopendbx_la-odbxlib.lo -MD -MP -MF .deps/libopendbx_la-odbxlib.Tpo -c odbxl
ib.c  -DDLL_EXPORT -DPIC -o .libs/libopendbx_la-odbxlib.o
odbxlib.c:259:2: error: #error "Building shared libraries requires capabilities
to load libraries dynamically"
make[2]: *** [libopendbx_la-odbxlib.lo] Error 1
make[2]: Leaving directory `/opendbx/lib'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/opendbx'
make: *** [all] Error 2

My configuration  was as follows.

$ CPPFLAGS="-Ic:/mingw/msys/1.0/local/include" LDFLAGS="-Lc:/mingw/msys/1.0/loc
al/lib" configure --disable-utils --with-backends="mssql"


Best Regards,


Miguel

Re: [opendbx] FW: [BUGS] BUG #5837: PQstatus() fails to report lost connection

[Murray S. K. <ms...@cl...>]

> -----Original Message-----
> From: Norbert Sendetzky [mailto:no...@li...]
> Sent: Tuesday, January 25, 2011 3:01 PM
> To: OpenDBX devel list
> Subject: Re: [opendbx] FW: [BUGS] BUG #5837: PQstatus() fails to report lost connection
> 
> If I understood your explanation right, we have a third possibility if
> we manage to return a fatal error when calling odbx_error_type() after
> we got PGRES_FATAL_ERROR from PGgetResultStatus() in odbx_result(). In
> this case we shouldn't care about what PQstatus() is saying as it
> doesn't know what's going on.
> 
> What do you think?

I thought of that too.  The only concern there is that you might insist on a restart (odbx_error_type() returning -1) when it's not actually needed, because unfortunately PGgetResultStatus() can report a fatal error when the connection is intact but the transaction was fatal; there's no way to distinguish the two.  So while this would certainly work to make the result more reliable, it would also mean a degradation in performance because of potentially unnecessary reconnections.

In OpenDKIM what I've actually done is to add a compile-time flag that will extract the error string when odbx_result() returns -1; if the string says "FATAL:" in it, then I pretend odbx_error_type() returned -1 and arrange for a reconnect.  That way, I hope, I avoid reconnects when the query was fatal but the connection is fine, and otherwise provide reasonably reliable service.  That way the user can decide, for now, whether to use libpq as defined (broken, IMHO) or try to work around it with some possibility for penalty.

-MSK

Re: [opendbx] FW: [BUGS] BUG #5837: PQstatus() fails to report lost connection

[Norbert S. <no...@li...>]

Hi Murray

> So unless they have a change of heart and actually fix this, it
> sounds like you're going to have to call PGgetResult() repeatedly,
> caching all the possible results, on the first call to odbx_result(),
> and then pull them out one at a time when the user calls it again.
> That's the only way PQstatus() will tell you the truth on a fatal
> error.

Not a good idea, especially if the library needs to hold the rows of 
each result set in memory as well. This would be the opposite of what 
I've tried to provide: A fast library with low memory consumption.

> Or, you could "pass the buck" and require your users to do the same
> thing as libpq, namely keep calling odbx_result() until the end of
> the result set is reached, so that you get the "true" PQstatus()
> value and then the user can use odbx_error_type() with correct
> results.

This is also not a solution I would consider as it violates the second 
principle of the OpenDBX library: Provide a layer which works the same 
for all underlying databases and don't force the users to care about the 
differences.

If I understood your explanation right, we have a third possibility if 
we manage to return a fatal error when calling odbx_error_type() after 
we got PGRES_FATAL_ERROR from PGgetResultStatus() in odbx_result(). In 
this case we shouldn't care about what PQstatus() is saying as it 
doesn't know what's going on.

What do you think?


Norbert

Re: [opendbx] FW: [BUGS] BUG #5837: PQstatus() fails to report lost connection

[Murray S. K. <ms...@cl...>]

> -----Original Message-----
> From: Norbert Sendetzky [mailto:no...@li...]
> Sent: Tuesday, January 25, 2011 2:30 PM
> To: OpenDBX devel list
> Subject: Re: [opendbx] FW: [BUGS] BUG #5837: PQstatus() fails to report lost connection
> 
> > This will require some changes to lib/backends/pgsql_basic.c and/or
> > the OpenDBX documentation, I'm afraid.
> 
> Could you explain to me in detail where the changes must happen? Then I
> will see to make an update soon.

The background: A connection is established, some queries are run and return successfully.  Then postgresql is deliberately restarted.

Here's what you're doing.  A call to odbx_query() after the restart returns normally (which is strange by itself...).  In odbx_result(), you:

- call PGgetResult(), it returns non-NULL
- call PGgetResultStatus(), it reports PGRES_FATAL_ERROR
- call PQstatus(), it returns CONNECTION_OK
- you return -1

Then I call odbx_error_type(), which remembers that the handle got PGRES_FATAL_ERROR but also got CONNECTION_OK, so it just returns 1 (no reconnect required).  The reason PQstatus() appears to give a false result is because the TCP part of the connection was fine (there was no I/O error; EOF hasn't been reached).  Interestingly enough if you ask for the error string matching the fatal error at this point, it does tell you that the connection has been reset by administrator action.

The problem now is that, since no reconnect is attempted, all future queries fail on that handle.

The issue is that PQstatus() relies on internal state that has not been updated to reflect that the connection is dead.  According to the libpq people, that's because you didn't repeat PGgetResult() until it returned NULL.    I guess on an administrative restart of the server, all connections are notified of this, so there's I/O pending for read on the socket at the client.  odbx_result() causes this message to be read, but EOF isn't reached yet so PQstatus() continues to show the connection as usable.  So apparently you have to call PGgetResult() again anyway, even though PGgetResultStatus() has indicated a fatal error.  I agree that this seems strange; I likened it to select() returning an indication that some descriptor is read-ready but also has an exception, and then stating that the user needs to call read() repeatedly until EOF just to get errno to tell you what happened.

So unless they have a change of heart and actually fix this, it sounds like you're going to have to call PGgetResult() repeatedly, caching all the possible results, on the first call to odbx_result(), and then pull them out one at a time when the user calls it again.  That's the only way PQstatus() will tell you the truth on a fatal error.

Or, you could "pass the buck" and require your users to do the same thing as libpq, namely keep calling odbx_result() until the end of the result set is reached, so that you get the "true" PQstatus() value and then the user can use odbx_error_type() with correct results.

Neither solution is especially pretty.

> Thanks for your help

My pleasure.  Sorry for the bad news.   :-)

-MSK

Re: [opendbx] OpenDBX future

[Norbert S. <no...@li...>]

Hi Mariano

> Hope everything is fine. There are a group of students in
> Argentina that wants to push even more SqueakDBX and create some more
> functionalities. Now, I wonder which is the status of OpenDBX. Do you have
> plans to continue with it? continue the development, etc?

At the moment I've very little time for implementing new things and I 
don't know exactly when it might get better. On the other side, it would 
be great to add new features to the library, especially the prepared 
statement part is a key functionality I would like to see in the 
library. At the moment my biggest hope is that people will send patches 
for functionality they need and which they would like to get included in 
the official version of the library.


Norbert

Re: [opendbx] FW: [BUGS] BUG #5837: PQstatus() fails to report lost connection

[Norbert S. <no...@li...>]

Hi Murray

> It looks like the position of the libpq people is that calling
> PQresultStatus() is not appropriate until after PQgetResult() has
> returned NULL.  Only then will PQstatus() give you a correct
> indication after PQresultStatus() has returned PGRES_FATAL_ERROR.
> They're proposing updating their documentation to reflect this rather
> than implementing a fix to keep the API clean.

I'm afraid too! Instead of providing a good API and polishing rough 
edges, they turn on the path of least resistance ...

> This will require some changes to lib/backends/pgsql_basic.c and/or
> the OpenDBX documentation, I'm afraid.

Could you explain to me in detail where the changes must happen? Then I 
will see to make an update soon.

Thanks for your help


Norbert

[opendbx] OpenDBX future

[Mariano M. P. <mar...@gm...>]

Hi Norbert. Hope everything is fine. There are a group of students in
Argentina that wants to push even more SqueakDBX and create some more
functionalities. Now, I wonder which is the status of OpenDBX. Do you have
plans to continue with it? continue the development, etc?

thanks in advance,

Mariano

Re: [opendbx] FW: [BUGS] BUG #5837: PQstatus() fails to report lost connection

[Murray S. K. <ms...@cl...>]

Hi Norbert,

It looks like the position of the libpq people is that calling PQresultStatus() is not appropriate until after PQgetResult() has returned NULL.  Only then will PQstatus() give you a correct indication after PQresultStatus() has returned PGRES_FATAL_ERROR.  They're proposing updating their documentation to reflect this rather than implementing a fix to keep the API clean.

This will require some changes to lib/backends/pgsql_basic.c and/or the OpenDBX documentation, I'm afraid.

-MSK

[opendbx] FW: [BUGS] BUG #5837: PQstatus() fails to report lost connection

[Murray S. K. <ms...@cl...>]

This was my reply to the pgsql-bugs list when I reported the PQstatus() issue.  I think they're punting when they should fix it, but someone else with more experience using libpq might be better to speak up here.

Re: [opendbx] odbx_error_type() issue

[Norbert S. <no...@li...>]

Hi Murray

> The former seems to be the case, using postgres 9.0.2.  Has anyone
> seen this?  Is there a patch or a workaround?

I was not aware of this before. If it's a change/bug in PostgresSQL, I 
can't do much.


Norbert

Re: [opendbx] odbx_error_type() issue

[Murray S. K. <ms...@cl...>]

The former seems to be the case, using postgres 9.0.2.  Has anyone seen this?  Is there a patch or a workaround?

I'll see if I can get some results from that group as well.

-MSK

From: Murray S. Kucherawy [mailto:ms...@cl...]
Sent: Thursday, January 13, 2011 3:11 PM
To: OpenDBX devel list
Subject: Re: [opendbx] odbx_error_type() issue

I looked through pgsql_odbx_result() in 1.4.5 and it seems that one of two things is happening:

-          PQstatus() is falsely reporting that the connection is still useable (i.e. it's not returning CONNECTION_BAD when it should)

-          PQresultStatus() is not returning PGRES_FATAL_ERROR, which causes the PQstatus() check to be bypassed

I'll see if I can get more information about which of these is happening.  As for the "why", I'm a little scared about the idea of diving into libpq source, so maybe someone more familiar with it can help out here.

-MSK

From: Murray S. Kucherawy [mailto:ms...@cl...]
Sent: Thursday, January 13, 2011 1:33 PM
To: OpenDBX devel list
Subject: Re: [opendbx] odbx_error_type() issue

It's actually odbx_result() that's returning -1 while odbx_error_type() returns 1 in the scenario described, which fails to trigger the reconnect attempt.  The call to odbx_query() appears to be returning 0.
Versions: opendbx 1.4.5, postgresql and pqlib 9.0.2

-MSK

From: Murray S. Kucherawy [mailto:ms...@cl...]
Sent: Wednesday, January 12, 2011 1:54 PM
To: lib...@li...
Subject: [opendbx] odbx_error_type() issue

I have an application using opendbx that tries the sequence suggested by the opendbx documentation to do a query; specifically, I have a "get" function that basically does this:

err = odbx_query(db, ...);
if (err < 0)
{
   if (odbx_error_type(db, err) < 0)
   {
      odbx_unbind(db);
      odbx_finish(db);
      odbx_init(&db, ...);
      odbx_bind(db, ...);
      err = odbx_query(db, ...);
      if (err < 0)
        return err;
   }
   else
   {
      return err;
   }
   parse_result(db, ...);
}

I've got a user reporting that a connection lost to a postgresql server results in an error from our application.  The postgresql error we get back is:

FATAL:  terminating connection due to administrator command

A web search suggests this is the result of a deliberate server shutdown.  An odbx_query() then, predictably, fails, but should run through the reconnect attempt described above.  In a test with MySQL, a first "get" succeeds, then after I terminated and restart MySQL, a second "get" runs through the reconnect logic and the inner odbx_query() then succeeds.

In a similar restart-after-query test with postgresql, the "get" returns the above error.  I'm waiting for more data from the reporting user but it would appear the fatal error reported by that backend isn't causing odbx_error_type() to return -1, so the reconnect isn't attempted and an error is returned.  When I can confirm this I'll follow-up.  I also don't yet have the versions of postgresql library or server, or the version of opendbx, in use in this scenario.

In the interim, does this ring any bells?  Is this a known issue, or am I doing something wrong with my use of the API?

Thanks,
-MSK

Re: [opendbx] odbx_error_type() issue

[Murray S. K. <ms...@cl...>]

I looked through pgsql_odbx_result() in 1.4.5 and it seems that one of two things is happening:


-          PQstatus() is falsely reporting that the connection is still useable (i.e. it's not returning CONNECTION_BAD when it should)

-          PQresultStatus() is not returning PGRES_FATAL_ERROR, which causes the PQstatus() check to be bypassed

I'll see if I can get more information about which of these is happening.  As for the "why", I'm a little scared about the idea of diving into libpq source, so maybe someone more familiar with it can help out here.

-MSK

From: Murray S. Kucherawy [mailto:ms...@cl...]
Sent: Thursday, January 13, 2011 1:33 PM
To: OpenDBX devel list
Subject: Re: [opendbx] odbx_error_type() issue

It's actually odbx_result() that's returning -1 while odbx_error_type() returns 1 in the scenario described, which fails to trigger the reconnect attempt.  The call to odbx_query() appears to be returning 0.
Versions: opendbx 1.4.5, postgresql and pqlib 9.0.2

-MSK

From: Murray S. Kucherawy [mailto:ms...@cl...]
Sent: Wednesday, January 12, 2011 1:54 PM
To: lib...@li...
Subject: [opendbx] odbx_error_type() issue

I have an application using opendbx that tries the sequence suggested by the opendbx documentation to do a query; specifically, I have a "get" function that basically does this:

err = odbx_query(db, ...);
if (err < 0)
{
   if (odbx_error_type(db, err) < 0)
   {
      odbx_unbind(db);
      odbx_finish(db);
      odbx_init(&db, ...);
      odbx_bind(db, ...);
      err = odbx_query(db, ...);
      if (err < 0)
        return err;
   }
   else
   {
      return err;
   }
   parse_result(db, ...);
}

I've got a user reporting that a connection lost to a postgresql server results in an error from our application.  The postgresql error we get back is:

FATAL:  terminating connection due to administrator command

A web search suggests this is the result of a deliberate server shutdown.  An odbx_query() then, predictably, fails, but should run through the reconnect attempt described above.  In a test with MySQL, a first "get" succeeds, then after I terminated and restart MySQL, a second "get" runs through the reconnect logic and the inner odbx_query() then succeeds.

In a similar restart-after-query test with postgresql, the "get" returns the above error.  I'm waiting for more data from the reporting user but it would appear the fatal error reported by that backend isn't causing odbx_error_type() to return -1, so the reconnect isn't attempted and an error is returned.  When I can confirm this I'll follow-up.  I also don't yet have the versions of postgresql library or server, or the version of opendbx, in use in this scenario.

In the interim, does this ring any bells?  Is this a known issue, or am I doing something wrong with my use of the API?

Thanks,
-MSK

Re: [opendbx] odbx_error_type() issue

[Murray S. K. <ms...@cl...>]

It's actually odbx_result() that's returning -1 while odbx_error_type() returns 1 in the scenario described, which fails to trigger the reconnect attempt.  The call to odbx_query() appears to be returning 0.

Versions: opendbx 1.4.5, postgresql and pqlib 9.0.2

-MSK

From: Murray S. Kucherawy [mailto:ms...@cl...]
Sent: Wednesday, January 12, 2011 1:54 PM
To: lib...@li...
Subject: [opendbx] odbx_error_type() issue

I have an application using opendbx that tries the sequence suggested by the opendbx documentation to do a query; specifically, I have a "get" function that basically does this:

err = odbx_query(db, ...);
if (err < 0)
{
   if (odbx_error_type(db, err) < 0)
   {
      odbx_unbind(db);
      odbx_finish(db);
      odbx_init(&db, ...);
      odbx_bind(db, ...);
      err = odbx_query(db, ...);
      if (err < 0)
        return err;
   }
   else
   {
      return err;
   }
   parse_result(db, ...);
}

I've got a user reporting that a connection lost to a postgresql server results in an error from our application.  The postgresql error we get back is:

FATAL:  terminating connection due to administrator command

A web search suggests this is the result of a deliberate server shutdown.  An odbx_query() then, predictably, fails, but should run through the reconnect attempt described above.  In a test with MySQL, a first "get" succeeds, then after I terminated and restart MySQL, a second "get" runs through the reconnect logic and the inner odbx_query() then succeeds.

In a similar restart-after-query test with postgresql, the "get" returns the above error.  I'm waiting for more data from the reporting user but it would appear the fatal error reported by that backend isn't causing odbx_error_type() to return -1, so the reconnect isn't attempted and an error is returned.  When I can confirm this I'll follow-up.  I also don't yet have the versions of postgresql library or server, or the version of opendbx, in use in this scenario.

In the interim, does this ring any bells?  Is this a known issue, or am I doing something wrong with my use of the API?

Thanks,
-MSK

[opendbx] odbx_error_type() issue

[Murray S. K. <ms...@cl...>]

I have an application using opendbx that tries the sequence suggested by the opendbx documentation to do a query; specifically, I have a "get" function that basically does this:

err = odbx_query(db, ...);
if (err < 0)
{
   if (odbx_error_type(db, err) < 0)
   {
      odbx_unbind(db);
      odbx_finish(db);
      odbx_init(&db, ...);
      odbx_bind(db, ...);
      err = odbx_query(db, ...);
      if (err < 0)
        return err;
   }
   else
   {
      return err;
   }
   parse_result(db, ...);
}

I've got a user reporting that a connection lost to a postgresql server results in an error from our application.  The postgresql error we get back is:

FATAL:  terminating connection due to administrator command

A web search suggests this is the result of a deliberate server shutdown.  An odbx_query() then, predictably, fails, but should run through the reconnect attempt described above.  In a test with MySQL, a first "get" succeeds, then after I terminated and restart MySQL, a second "get" runs through the reconnect logic and the inner odbx_query() then succeeds.

In a similar restart-after-query test with postgresql, the "get" returns the above error.  I'm waiting for more data from the reporting user but it would appear the fatal error reported by that backend isn't causing odbx_error_type() to return -1, so the reconnect isn't attempted and an error is returned.  When I can confirm this I'll follow-up.  I also don't yet have the versions of postgresql library or server, or the version of opendbx, in use in this scenario.

In the interim, does this ring any bells?  Is this a known issue, or am I doing something wrong with my use of the API?

Thanks,
-MSK

Re: [opendbx] linking problem with libpgsqlbackend.so

[Norbert S. <no...@li...>]

Hi Fiona

> Anyhow, when I run the php extension, getStats.so  I get this failure message:
>
> Loading backend library pgsql, libpgsql
> backend.so or /usr/local/lib/opendbx/libpgsql
> backend.so failed
> /usr/local/lib/opendbx/libpgsql
> backend.so: cannot open shared object file: No such file or directory
>
> when it tries to run odbx_init.
>
> The error message above is a bit odd, words are split.
> The *.so libraries seem fine when I do nm on them, not corrupted or anything.

Seems like your string "pgsql" for odbx_init() contains a newline at the 
end.


Norbert

[opendbx] linking problem with libpgsqlbackend.so

[Fiona S. <fio...@ya...>]

hello,
I'm trying to use opendbx in a php extension.
It seems to compile and link fine.
I get problems when I run the php extension.

I install opendbx -1.4.5 as follows:
CFLAGS="-I/usr/local/pgsql/include" LDFLAGS="-L/usr/local/pgsql/lib" ./configure 
--with-backend="pgsql" 

This put a bunch of .so files into /usr/local/lib like libopendbx.so, 
libopendbxplus.so
It also creates a sub-directory opendbx and puts libpgsqlbackend.so etc. there

Anyhow, I make and link my php_extension:
Make:
cc -DPHP_ATOM_INC -I < include files> -g -02 -c <source file> -fPIC -DPIC  -o 
<object file>
::

Link:
cc  -shared <object files> -Wl, -soname -Wl,getStats.so -o getStats.so -lopendbx

Anyhow, when I run the php extension, getStats.so  I get this failure message:

Loading backend library pgsql, libpgsql
backend.so or /usr/local/lib/opendbx/libpgsql
backend.so failed
/usr/local/lib/opendbx/libpgsql
backend.so: cannot open shared object file: No such file or directory

when it tries to run odbx_init.

The error message above is a bit odd, words are split. 
The *.so libraries seem fine when I do nm on them, not corrupted or anything.

Anyone got any ideas please?
thanks
Fiona

Re: [opendbx] ODBX_OPT_THREAD_SAFE

[Murray S. K. <ms...@cl...>]

> -----Original Message-----
> From: Norbert Sendetzky [mailto:no...@li...]
> Sent: Friday, September 17, 2010 9:35 AM
> To: OpenDBX devel list
> Subject: Re: [opendbx] ODBX_OPT_THREAD_SAFE
> 
> > Understood, but then I'm confused as to what this option's presence
> > is really telling me.  Is it saying "safe to use one connection with
> > many threads" or "safe to create multiple connections per thread" or
> > something else?
> 
> It states: "It's safe to use this backend in an application which
> consists of different threads using at least one connection".

Right, I find that wording a bit ambiguous.

> If odbx_get_option(ODBX_OPT_THREAD_SAFE) returns 0, you should only use
> this backend in applications where each process has it's own memory
> space. This is because at least one function in the native database
> client reuse the same statically allocated memory at each call.

So basically the backend library is using globals or something that's not thread-safe at all regardless of how one might use the library.  The description states one particular way that a multi-threaded program could use an API, so I wasn't clear on whether the flag discusses that specific possible use, versus any possible multi-threaded use.

I would suggest instead: "It is safe to use this backend in a multi-threaded application."

Cheers,
-MSK

Re: [opendbx] ODBX_OPT_THREAD_SAFE

[Norbert S. <no...@li...>]

Hi Murray

> Understood, but then I'm confused as to what this option's presence
> is really telling me.  Is it saying "safe to use one connection with
> many threads" or "safe to create multiple connections per thread" or
> something else?

It states: "It's safe to use this backend in an application which 
consists of different threads using at least one connection".

If odbx_get_option(ODBX_OPT_THREAD_SAFE) returns 0, you should only use 
this backend in applications where each process has it's own memory 
space. This is because at least one function in the native database 
client reuse the same statically allocated memory at each call.


Norbert

Re: [opendbx] ODBX_OPT_THREAD_SAFE

[Murray S. K. <ms...@cl...>]

Hi Norbert,

> -----Original Message-----
> From: Norbert Sendetzky [mailto:no...@li...]
> Sent: Friday, September 17, 2010 1:26 AM
> To: OpenDBX devel list
> Subject: Re: [opendbx] ODBX_OPT_THREAD_SAFE
> 
> [...]
> 
> It's usually more efficient if every thread uses its own connection to
> the database. Otherwise, your application have to care about locking
> when sending requests until they are finally retrieved. Please keep
> that
> in mind and this is nothing the native database libraries are able to
> care about automatically.

Understood, but then I'm confused as to what this option's presence is really telling me.  Is it saying "safe to use one connection with many threads" or "safe to create multiple connections per thread" or something else?