Thread: libpq on windows
Hi I'm having trouble using libpq.dll (implicit linking with C programs). I'm using libpq.dll v8.0.3.5131 (timestamp Wed May 11 11:12:58 2005) and PostgreSQL 8.0.3 on i686-pc-mingw32, compiled by GCC gcc.exe (GCC) 3.4.2 (mingw-special) v8.0.3.5131. I used both Borland C++ 5.5.1 and Microsoft (R) 32-bit C/C++ Standard Compiler Version 12.00.8168. The problem seems to occurr only when the server sends a hint or the dll generates one. This can happen when the connection to the server cannot be established because the server is not running, a nonexistant postgres function exist is called, when one attempts to drop an index upon which a constraint depends, etc. (the program doesn't go beyond PQconnectdb, PQexec or PQexecparam). Since my debugging skills are very poor I cannot give any accurate description on what is causing the exception. The problem can be very easily reproduced by creating a C program which calls PQconnectdb with a host parameter that points to a machine that is not running postgres. Running the same program under linux (although I used older versions of the interface and the server) does not cause any problems. Gustavo Lopes
On May 19, 2005, at 9:52 AM, Gustavo Lopes wrote: > The problem can be very easily reproduced by creating a C program > which calls PQconnectdb with a host parameter that points to a machine > that is not running postgres. > Running the same program under linux (although I used older versions > of the interface and the server) does not cause any problems. Try comparing what you are doing in this case to the psql source. It uses libpq and I run tests regularly that try connecting to an invalid server. I have not seen any problems. John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL
psql is too complex for me to analyze and I believe it's multithreaded
but anyway Ic ouldn't fathom anything substantially different when the
function PQsetdbLogin() is called (file startup.c).
It would probably be better to say what I've doing because it's
possible it's a mistake in some elementary aspect I haven't grasped.
Here is a sample program:
#include <libpq-fe.h>
#pragma comment(lib,"libpq.lib")
int main(void) {
PGconn *conn;
conn = PQconnectdb("host=localhost");
return 0;
}
The import library was created with "impdef -f -a libpq.lib libpq.dll"
(borland) and impdef/implib (vc++).
This program works only when postgresql is running.
Thanks in advance
Gustavo Lopes
On 19/05/05, John DeSoi <desoi@pgedit.com> wrote:
>
> On May 19, 2005, at 9:52 AM, Gustavo Lopes wrote:
>
> > The problem can be very easily reproduced by creating a C program
> > which calls PQconnectdb with a host parameter that points to a machine
> > that is not running postgres.
> > Running the same program under linux (although I used older versions
> > of the interface and the server) does not cause any problems.
>
> Try comparing what you are doing in this case to the psql source. It
> uses libpq and I run tests regularly that try connecting to an invalid
> server. I have not seen any problems.
>
>
> John DeSoi, Ph.D.
> http://pgedit.com/
> Power Tools for PostgreSQL
>
>
Attachment
Gustavo Lopes <contratempo@gmail.com> wrote: > The problem seems to occurr only when the server sends a hint or the > dll generates one. This can happen when the connection to the server > cannot be established because the server is not running, a nonexistant > postgres function exist is called, when one attempts to drop an index > upon which a constraint depends, etc. (the program doesn't go beyond > PQconnectdb, PQexec or PQexecparam). Since my debugging skills are > very poor I cannot give any accurate description on what is causing > the exception. > The problem can be very easily reproduced by creating a C program > which calls PQconnectdb with a host parameter that points to a machine > that is not running postgres. > Running the same program under linux (although I used older versions > of the interface and the server) does not cause any problems. It could be the notice processor that crashes. A "notice processor" is a callback that you can register with libpq that handles error messages. The default is to print them to the console, but I'm not sure you can always do that in a Windows program. Or since you're apparently using different compilers for libpq and the application, maybe the default notice processor gets linked to a different standard library than it expects and fails because of that. Notice processors are documented here: http://www.postgresql.org/docs/8.0/interactive/libpq-notice-processing.html To find out if this is what's wrong, try creating an empty function (with C-style calling convention, not a regular C++ function) and setting that as the notice processor: extern "C" { /* (this line only needed in C++) */ void emptynoticeprocessor(void *, const char *) { } } /* (this line onlyneeded in C++) */ Now in your code, just after you opened your connection (call it "c"): PQsetNoticeProcessor(c,emptynoticeprocessor,NULL); Of course that will mean that error messages are not displayed, so if this solves your crashing problem then your next step is to implement something here that displays the given message! Jeroen
No, I'd say the notice processor/receiver is not the problem since I've been able to implement a notice receiver that would display the received notices without any complications. The problem seems to arise only when a message contains a HINT attached (I don't even know whether messages of type NOTICE can cointain a hint field, but anyway that doesn't seem relevant to this issue). Gustavio Lopes On 20/05/05, jtv@xs4all.nl <jtv@xs4all.nl> wrote: > Gustavo Lopes <contratempo@gmail.com> wrote: > > > The problem seems to occurr only when the server sends a hint or the > > dll generates one. This can happen when the connection to the server > > cannot be established because the server is not running, a nonexistant > > postgres function exist is called, when one attempts to drop an index > > upon which a constraint depends, etc. (the program doesn't go beyond > > PQconnectdb, PQexec or PQexecparam). Since my debugging skills are > > very poor I cannot give any accurate description on what is causing > > the exception. > > The problem can be very easily reproduced by creating a C program > > which calls PQconnectdb with a host parameter that points to a machine > > that is not running postgres. > > Running the same program under linux (although I used older versions > > of the interface and the server) does not cause any problems. > > It could be the notice processor that crashes. A "notice processor" is a > callback that you can register with libpq that handles error messages. > The default is to print them to the console, but I'm not sure you can > always do that in a Windows program. Or since you're apparently using > different compilers for libpq and the application, maybe the default > notice processor gets linked to a different standard library than it > expects and fails because of that. > > Notice processors are documented here: > > http://www.postgresql.org/docs/8.0/interactive/libpq-notice-processing.html > > To find out if this is what's wrong, try creating an empty function (with > C-style calling convention, not a regular C++ function) and setting that > as the notice processor: > > extern "C" { /* (this line only needed in C++) */ > void emptynoticeprocessor(void *, const char *) > { > } > } /* (this line only needed in C++) */ > > Now in your code, just after you opened your connection (call it "c"): > > PQsetNoticeProcessor(c,emptynoticeprocessor,NULL); > > Of course that will mean that error messages are not displayed, so if this > solves your crashing problem then your next step is to implement something > here that displays the given message! > > Jeroen > >
Actually it seems the hints are not the problem. I see no pattern now. For instance, if table "j" doesn't exist, "drop table j" is ok but not "drop table". Gustavo Lopes On 20/05/05, Gustavo Lopes <contratempo@gmail.com> wrote: > No, I'd say the notice processor/receiver is not the problem since > I've been able to implement a notice receiver that would display the > received notices without any complications. > The problem seems to arise only when a message contains a HINT > attached (I don't even know whether messages of type NOTICE can > cointain a hint field, but anyway that doesn't seem relevant to this > issue). > > Gustavio Lopes > > On 20/05/05, jtv@xs4all.nl <jtv@xs4all.nl> wrote: > > Gustavo Lopes <contratempo@gmail.com> wrote: > > > > > The problem seems to occurr only when the server sends a hint or the > > > dll generates one. This can happen when the connection to the server > > > cannot be established because the server is not running, a nonexistant > > > postgres function exist is called, when one attempts to drop an index > > > upon which a constraint depends, etc. (the program doesn't go beyond > > > PQconnectdb, PQexec or PQexecparam). Since my debugging skills are > > > very poor I cannot give any accurate description on what is causing > > > the exception. > > > The problem can be very easily reproduced by creating a C program > > > which calls PQconnectdb with a host parameter that points to a machine > > > that is not running postgres. > > > Running the same program under linux (although I used older versions > > > of the interface and the server) does not cause any problems. > > > > It could be the notice processor that crashes. A "notice processor" is a > > callback that you can register with libpq that handles error messages. > > The default is to print them to the console, but I'm not sure you can > > always do that in a Windows program. Or since you're apparently using > > different compilers for libpq and the application, maybe the default > > notice processor gets linked to a different standard library than it > > expects and fails because of that. > > > > Notice processors are documented here: > > > > http://www.postgresql.org/docs/8.0/interactive/libpq-notice-processing.html > > > > To find out if this is what's wrong, try creating an empty function (with > > C-style calling convention, not a regular C++ function) and setting that > > as the notice processor: > > > > extern "C" { /* (this line only needed in C++) */ > > void emptynoticeprocessor(void *, const char *) > > { > > } > > } /* (this line only needed in C++) */ > > > > Now in your code, just after you opened your connection (call it "c"): > > > > PQsetNoticeProcessor(c,emptynoticeprocessor,NULL); > > > > Of course that will mean that error messages are not displayed, so if this > > solves your crashing problem then your next step is to implement something > > here that displays the given message! > > > > Jeroen > > > > >
Gustavo Lopes <contratempo@gmail.com> writes:
> Actually it seems the hints are not the problem. I see no pattern now.
> For instance, if table "j" doesn't exist, "drop table j" is ok but not
> "drop table".
Well, the latter generates a syntax complaint:
regression=# drop table j;
ERROR: table "j" does not exist
regression=# drop table ;
ERROR: syntax error at or near ";" at character 12
LINE 1: drop table ; ^
regression=#
Maybe the pattern is "any multi-line error message causes a problem"?
regards, tom lane
Is there any easy (ie, no C postgres functions) way to generate multi-line error messages so that I can explore that possibility? Gustavo Lopes On 20/05/05, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Gustavo Lopes <contratempo@gmail.com> writes: > > Actually it seems the hints are not the problem. I see no pattern now. > > For instance, if table "j" doesn't exist, "drop table j" is ok but not > > "drop table". > > Well, the latter generates a syntax complaint: > > regression=# drop table j; > ERROR: table "j" does not exist > regression=# drop table ; > ERROR: syntax error at or near ";" at character 12 > LINE 1: drop table ; > ^ > regression=# > > Maybe the pattern is "any multi-line error message causes a problem"? > > regards, tom lane >
Hi, On 5/21/05, Gustavo Lopes <contratempo@gmail.com> wrote: > Is there any easy (ie, no C postgres functions) way to generate > multi-line error messages so that I can explore that possibility? One way of generating mult-line error messages could be increasing verbosity level: => \set verbosity verbose => CREATE TABLE del_me_1 (id1 integer PRIMARY KEY); => CREATE TABLE del_me_2 (id2 integer REFERENCES del_me_1 (id1) ); => DROP TABLE del_me_1; NOTICE: constraint del_me_2_id2_fkey on table del_me_2 depends on table del_me_1 ERROR: cannot drop table del_me_1 because other objects depend on it HINT: Use DROP ... CASCADE to drop the dependent objects too. HTH. Regards.
I've done a couple of tests and in all my tests I see no problems with multiline error messages. Also, if I read your original post right, yuou're seeing the problem in a program that does a simple "PQconnectdb()" to a server that's not running, in which case the normal errormsg-from-backend routines are definitly not involved. it looks more like "random errors" to me. Do you see this problem if you use the psql.exe command to connect to the very same machine? Since psql.exe uses libpq, if it works there, then it's not "deep inside libpq" at least. It looks like you are using Borland C++ to compile your program, right? Could you try the same program compiled with the MingW compiler? It could be that your import library is somehow incorrect (say bad function calling conventions, bad function ordering or something), which would lead to strange errors. Your simple test program from http://archives.postgresql.org/pgsql-interfaces/2005-05/msg00044.php works just fine in my installation - it doesn't do anything, but it doesn't crash either. Compiled with MingW that is, I don't have Borland to test with. And with manual linking and not the #pragma link, because that appears to be a Borlandism. //Magnus >Is there any easy (ie, no C postgres functions) way to generate >multi-line error messages so that I can explore that possibility? > >Gustavo Lopes > >On 20/05/05, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Gustavo Lopes <contratempo@gmail.com> writes: >> > Actually it seems the hints are not the problem. I see no >pattern now. >> > For instance, if table "j" doesn't exist, "drop table j" >is ok but not >> > "drop table". >> >> Well, the latter generates a syntax complaint: >> >> regression=# drop table j; >> ERROR: table "j" does not exist >> regression=# drop table ; >> ERROR: syntax error at or near ";" at character 12 >> LINE 1: drop table ; >> ^ >> regression=# >> >> Maybe the pattern is "any multi-line error message causes a problem"? >> >> regards, tom lane >> > >---------------------------(end of >broadcast)--------------------------- >TIP 9: the planner will ignore your desire to choose an index >scan if your > joining column's datatypes do not match >
There were no problems with the executables when I compiled them with MingW. I've also been able to compile working executables with VC++ by using the /MD option - link with msvcrt runtime library, which MingW and libpq.dll also use (I found this by accident). While this really mitigates my problem (I am able to build working executables), this behaviour is still a mystery to me so any comments would be appreciated. Gustavo Lopes On 22/05/05, Magnus Hagander <mha@sollentuna.net> wrote: > I've done a couple of tests and in all my tests I see no problems with > multiline error messages. > > Also, if I read your original post right, yuou're seeing the problem in > a program that does a simple "PQconnectdb()" to a server that's not > running, in which case the normal errormsg-from-backend routines are > definitly not involved. it looks more like "random errors" to me. > > Do you see this problem if you use the psql.exe command to connect to > the very same machine? Since psql.exe uses libpq, if it works there, > then it's not "deep inside libpq" at least. > > It looks like you are using Borland C++ to compile your program, right? > Could you try the same program compiled with the MingW compiler? It > could be that your import library is somehow incorrect (say bad function > calling conventions, bad function ordering or something), which would > lead to strange errors. > > Your simple test program from > http://archives.postgresql.org/pgsql-interfaces/2005-05/msg00044.php > works just fine in my installation - it doesn't do anything, but it > doesn't crash either. Compiled with MingW that is, I don't have Borland > to test with. And with manual linking and not the #pragma link, because > that appears to be a Borlandism. > > //Magnus > > > >Is there any easy (ie, no C postgres functions) way to generate > >multi-line error messages so that I can explore that possibility? > > > >Gustavo Lopes > > > >On 20/05/05, Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> Gustavo Lopes <contratempo@gmail.com> writes: > >> > Actually it seems the hints are not the problem. I see no > >pattern now. > >> > For instance, if table "j" doesn't exist, "drop table j" > >is ok but not > >> > "drop table". > >> > >> Well, the latter generates a syntax complaint: > >> > >> regression=# drop table j; > >> ERROR: table "j" does not exist > >> regression=# drop table ; > >> ERROR: syntax error at or near ";" at character 12 > >> LINE 1: drop table ; > >> ^ > >> regression=# > >> > >> Maybe the pattern is "any multi-line error message causes a problem"? > >> > >> regards, tom lane > >> > > > >---------------------------(end of > >broadcast)--------------------------- > >TIP 9: the planner will ignore your desire to choose an index > >scan if your > > joining column's datatypes do not match > > >
psql is too complex for me to analyze and I believe it's multithreaded
but anyway Ic ouldn't fathom anything substantially different when the
function PQsetdbLogin() is called (file startup.c).
It would probably be better to say what I've doing because it's
possible it's a mistake in some elementary aspect I haven't grasped.
Here is a sample program:
#include <libpq-fe.h>
#pragma comment(lib,"libpq.lib")
int main(void) { PGconn *conn; conn = PQconnectdb("host=localhost"); return 0;
}
The import library was created with "impdef -f -a libpq.lib libpq.dll"
(borland) and impdef/implib (vc++).
This program works only when postgresql is running.
Thanks in advance
Gustavo Lopes
-----
--
View this message in context: http://postgresql.1045698.n5.nabble.com/Re-INTERFACES-libpq-on-windows-tp5735413.html
Sent from the PostgreSQL - interfaces mailing list archive at Nabble.com.