I'm not able to connect with Base to my PostgreSQL server. The problem occurs on a Mac (OS X 10.6.8) with LibreOffice 3.5.0rc3. The following is how I set up the connection on a Mac: 1. Connection to an existing database: PostgreSQL 2. Datasource URL: I tried several: - dbname=<my-database> - hostaddr=<ip> dbname=<my-database> - hostaddr=localhost dbname=<my-database> 3. Provide authenticated username and password 4. Running "Test connection", prints the errormessage: "The connection could not be established" - without any details. The problem doesn't occur on Windows XP with LibreOffice 3.5.0rc3. It connects with the PostgreSQL server on the previous mentoined Mac. (PostgreSQL listens to all hosts on port 5432). Also on Windows XP, I get a more detailed errormessage, when the connection can't be established. The following is how I set up the WORKING connection on Windows XP: 1. Connection to an existing database: PostgreSQL 2. Datasource URL: hostaddr=<ip-postgresql-server-mac> dbname=<my-database> 3. Provide authenticated username and password 4. Running "Test connection" and Connect are successful. Also, no problem via jdbc on the same Mac. I'm pondering whether it could be a LibreOffice platform issue (Mac vs Windows packaging?).
Alexander: I think you have a MacOS machine, right? Could you please test/confirm whether PostgreSQL-SDBC works for you? Bob: when you get the error message "The connection could not be established". Please click on the "more" button. There could be multiple errors in the error list in the left part of the "Details" dialog (the one that opens when you click "more". Click each of them. Are there any more details there?
Hi Lionel, I'll fire up my Mac a bit later today and have a look. Alex
Confirming on Mac OSX 10.6.8 with release LO 3.5. I can however connect via JDBC using the ad hoc driver without a problem. I get the same error message as the initial reporter. Alex
Lionel: Unfortunately there's not such "more" button, like there's in Windows. I noticed that difference. It's too bad I can't provide you more details I did.1
Well, without more information (or access to a MacOS X machine), there's not much I can do :-| Let's try to get information in other ways: - Does LibreOffice actually open a TCP connection to the PostgreSQL server? This can e.g. be seen with tools like Wireshark. - What is PostgreSQL's view of the connection? Increase the logging level of the server, e.g.: client_min_messages(LOG) log_min_messages(INFO) log_min_error_statement(INFO) log_connections(true) log_disconnections(true) log_error_verbosity (VERBOSE) - Enable PostgreSQL-SDBC logging: Edit file /installation/prefix/program/postgresql-sdbc.ini Change PQ_LOGLEVEL=NONE to PQ_LOGLEVEL=INFO Restart LibreOffice, try to connect to PostgreSQL. This will create a file "sdbc-pqsql.log" in the current directory.
(In reply to comment #4) > Lionel: Unfortunately there's not such "more" button, like there's in Windows. This could be a MacOS-specific bug in its own right. Could you please report it separately so that it is taken up by a MacOS/GUI LibreOffice contributor? Thanks.
(In reply to comment #5) > > - Does LibreOffice actually open a TCP connection to the PostgreSQL server? > This can e.g. be seen with tools like Wireshark. No. I checked this with netstat. > > - What is PostgreSQL's view of the connection? Increase the logging level of > the server, e.g.: > client_min_messages(LOG) > log_min_messages(INFO) > log_min_error_statement(INFO) > log_connections(true) > log_disconnections(true) > log_error_verbosity (VERBOSE) > > - Enable PostgreSQL-SDBC logging: > Edit file /installation/prefix/program/postgresql-sdbc.ini > Change PQ_LOGLEVEL=NONE > to PQ_LOGLEVEL=INFO > Restart LibreOffice, try to connect to PostgreSQL. This will create a file > "sdbc-pqsql.log" in the current directory. I don't know in which path the logfile should be written. There's no logfile written, in directory /Applications/LibreOffice.app Is there still some change to debug?
(In reply to comment #7) > (In reply to comment #5) >> - Does LibreOffice actually open a TCP connection to the PostgreSQL server? >> This can e.g. be seen with tools like Wireshark. > No. I checked this with netstat. Netstat show currently open TCP connections. If LibreOffice opens a TCP connection, gets an error from the PostgreSQL server and immediately closes the connection, you won't see it with netstat, unless you run netstat at exactly the right time (within a fraction of a second). > > - What is PostgreSQL's view of the connection? Increase the logging level of > > the server, (...) >> - Enable PostgreSQL-SDBC logging: >> Edit file /installation/prefix/program/postgresql-sdbc.ini >> Change PQ_LOGLEVEL=NONE >> to PQ_LOGLEVEL=INFO >> Restart LibreOffice, try to connect to PostgreSQL. This will create a file >> "sdbc-pqsql.log" in the current directory. > I don't know in which path the logfile should be written. PostgreSQL server log: that's configured in the server configuration. Can be a specific file or the syslog. PostgreSQL-SDBC: The current directory, the directory you started LibreOffice from. Dunno what that is if you start it from a GUI on MacOS X, but maybe something like: lsof -p $( ps axc|awk "{if (\$5==\"soffice.bin\") print \$1}" ) | grep cwd will tell you, assuming: - LibreOffice is running - The LibreOffice process name on MacOS X is "soffice.bin" (without the quotes) - the "lsof" output is similar enough to what it is on GNU/Linux You can also try something like: lsof -p $( ps axc|awk "{if (\$5==\"soffice.bin\") print \$1}" ) | grep sdbc or run "ps -A | grep soffice", take note of the process ID and use lsop -p THE_NUMBER_HERE directly.
lsof, show me processes: /Applications/LibreOffice.app/Contents/MacOS/postgresql-sdbc.uno.dylib /Applications/LibreOffice.app/Contents/MacOS/libsdbc2.dylib Logging (syslog) of PostgreSQL server, with the debug5 and verbose settings didn't show any connections of soffice, sdbc, or it's processid. Last week I also did a netcat (nc) scan on the port, awaiting for connections. LibreOffice postgres-sdbc didn't show up. However the psql (client) show a connection.
Ooops forgot to set confirmed status. Done.
Hi Lionel, On my build from master today (2012-03-09), I can connect to a running instance of postgres hosting the XTuple Demo (http://www.xtuple.com/) with the following connection string in the first dialog : dbname=demo host=localhost port=5432 (all on one line separated by a space between each key pair) and then in the second dialog the 'user' and 'password' This works for me. @Bob, please try with 3.5.1RC2 and see if you can connect to that with a connection string similar to mine. Alex
(In reply to comment #0) Hi Bob, > > 2. Datasource URL: I tried several: > - dbname=<my-database> > - hostaddr=<ip> dbname=<my-database> > - hostaddr=localhost dbname=<my-database> > After testing with my build from master today, the string : hostaddr='' throws an error message, see attached screenshot. If you switch to host='', then the connection should work. Alex
Created attachment 58247 [details] postgres connection string error with hostaddr keyword
@Alex, hostaddr is the "Numeric IP address of host to connect to" (see the docs: http://www.postgresql.org/docs/current/static/libpq-connect.html) I still can't connect with 3.5.1 RC2. The same results I reported in this thread.
(In reply to comment #14) > @Alex, hostaddr is the "Numeric IP address of host to connect to" (see the > docs: http://www.postgresql.org/docs/current/static/libpq-connect.html) > > I still can't connect with 3.5.1 RC2. > The same results I reported in this thread. Hi Bob, Let me test it some more on the latest RC and get back to you. Alex
Confirming that this doesn't work with a fresh install of 3.5.1 RC2 today, so at at guess, the buildbot for Mac is not building with the right switches, since with my build from master I could connect. Alex
Alex, thank you for let us know. Because the release policy etc of LiberOffice is unknown to me.. Does anybody know whether, and maybe when (next RC ?), this will be fixed in a Mac binary?
Here are my build switches, which build a master DMG package whereby I can connect to a running psql instance as described in my previous comments : This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by LibreOffice configure 3.6, which was generated by GNU Autoconf 2.61. Invocation command line was $ ./configure CC=ccache gcc-4.0 CXX=ccache g++-4.0 --with-max-jobs=4 --with-num-cpus=2 --with-vendor=The Document Foundation --enable-epm --enable-binfilter --disable-cairo-canvas --with-java-target-version=1.5 --enable-ext-presenter-minimizer --enable-ext-presenter-console --enable-ext-pdfimport --enable-ext-wiki-publisher --enable-ext-report-builder --enable-ext-scripting-beanshell --enable-ext-scripting-javascript --enable-ext-nlpsolver --enable-extension-integration --enable-online-update --without-system-postgresql --enable-epm --with-epm=internal --enable-python=auto --disable-systray --enable-extra-gallery --enable-extra-template --enable-extra-sample --enable-extra-font --enable-ext-numbertext --enable-ext-oooblogger --enable-ext-google-docs --enable-ext-diagram --enable-ext-barcode --enable-ext-mysql-connector --with-libmysql-path=/Users/Shared/LO/mysql-connector-c-6.0.2-osx10.5-x86-32bit --enable-binfilter --enable-ext-watch-window --disable-mozilla --disable-mozilla-build --without-doxygen In theory, the only one relevant to posgtres in there is : --without-system-postgresql Alex
(In reply to comment #17) > Alex, thank you for let us know. > > Because the release policy etc of LiberOffice is unknown to me.. > Does anybody know whether, and maybe when (next RC ?), this will be fixed in a > Mac binary? Hi Bob, RC2 may well become final (I haven't checked to see what might be blocking the release) unless this can be considered a blocker sufficiently important enough, although I doubt Petr would consider it to be so, since it only affects one OS. I'll poke the dev list to try and gauge a reaction. Alex
Oh well, guess it just wasn't going to happen - I've just seen the announcement for 3.5.1 by Italo, so at the earliest, this can only be fixed for 3.5.2. http://wiki.documentfoundation.org/ReleasePlan according to which it should be : Week 14, Apr 2 - Apr 8, 2012 Alex
We should fix it ASAP => increasing the severity. It is not a blocker because it affects only limited group of users. Note that MAC has many users but I think that only some of them are working with PostgreSQL.
(In reply to comment #18) > Here are my build switches, which build a master DMG package whereby I can > connect to a running psql instance as described in my previous comments : > > This file contains any messages produced by compilers while > running configure, to aid debugging if configure makes a mistake. > > It was created by LibreOffice configure 3.6, which was > generated by GNU Autoconf 2.61. Invocation command line was > > $ ./configure CC=ccache gcc-4.0 CXX=ccache g++-4.0 --with-max-jobs=4 > --with-num-cpus=2 --with-vendor=The Document Foundation --enable-epm > --enable-binfilter --disable-cairo-canvas --with-java-target-version=1.5 > --enable-ext-presenter-minimizer --enable-ext-presenter-console > --enable-ext-pdfimport --enable-ext-wiki-publisher --enable-ext-report-builder > --enable-ext-scripting-beanshell --enable-ext-scripting-javascript > --enable-ext-nlpsolver --enable-extension-integration --enable-online-update > --without-system-postgresql --enable-epm --with-epm=internal > --enable-python=auto --disable-systray --enable-extra-gallery > --enable-extra-template --enable-extra-sample --enable-extra-font > --enable-ext-numbertext --enable-ext-oooblogger --enable-ext-google-docs > --enable-ext-diagram --enable-ext-barcode --enable-ext-mysql-connector > --with-libmysql-path=/Users/Shared/LO/mysql-connector-c-6.0.2-osx10.5-x86-32bit > --enable-binfilter --enable-ext-watch-window --disable-mozilla > --disable-mozilla-build --without-doxygen > > > In theory, the only one relevant to posgtres in there is : > --without-system-postgresql 3.5.1 is build with --wuth-system-postgresql master use the default (--without) That can explain the difference.
(In reply to comment #22) > 3.5.1 is build with --wuth-system-postgresql > master use the default (--without) > That can explain the difference. Yes, that's probably exactly the thing: System PostgreSQL is AFAIK available only on MacOS X Lion (10.7) and later. So this means that current LibreOffice 3.5.0/1 should connect successfully to PostgreSQL on MacOS X 10.7. Can anybody test that?
(In reply to comment #22) > 3.5.1 is build with --wuth-system-postgresql Err... According to http://cgit.freedesktop.org/libreoffice/core/tree/distro-configs/LibreOfficeMacOSX.conf?h=libreoffice-3-5-1 and http://cgit.freedesktop.org/libreoffice/core/tree/distro-configs/LibreOfficeMacOSX.conf?h=libreoffice-3-5-0, both 3.5.0 and 3.5.1 have "--without-system-postgresql". Or are the official build flags not taken from this file? Where are they taken from then? And where can I change them :)
(In reply to comment #24) > (In reply to comment #22) > > 3.5.1 is build with --wuth-system-postgresql > > Err... According to > http://cgit.freedesktop.org/libreoffice/core/tree/distro-configs/LibreOfficeMacOSX.conf?h=libreoffice-3-5-1 > and > http://cgit.freedesktop.org/libreoffice/core/tree/distro-configs/LibreOfficeMacOSX.conf?h=libreoffice-3-5-0, > both 3.5.0 and 3.5.1 have "--without-system-postgresql". Or are the official > build flags not taken from this file? Where are they taken from then? And where > can I change them :) The release build for 3.5 were still with 'local' flag that turn that into using system-postgresql due to the first iteration when internal support was broken... I did not flip them back after that got fixed: my bad. I have removed the local flags now... so the 3.5.2.* series will use internal postgres. I nonetheless think that we should _not_ use an internal client for this. If someone has a need to connect natively to a postgress database, surely he has a client installed on the machine already... In any case if there is an 'option' both should work or that option should be disabled on that platform.
So what do you'all consider? - Releasing 3.5.2 (RC.?) with-- OR without-system-postgresql? - Or making this even configurable? Is that a lot of work? Anyway, I hope that there will be a working binary soon. I think some Mac users really appreciate that. So I'll have to wait until the beginning of April?
(In reply to comment #25) > I have removed the local flags now... so the 3.5.2.* series will use internal > postgres. Great, so setting as resolved/fixed for 3.5.2. > I nonetheless think that we should _not_ use an internal client for this. > If someone has a need to connect natively to a postgress database, > surely he has a client installed on the machine already... I'd expect it would usually be the case for the "single user" case, but not always in an enterprise configuration. For example, I use LibreOffice internally @work for nice GUI to access to data in PostgreSQL. *I* have another client installed on my developent machine, but as LibreOffice comes with its own, the "normal users" don't have any other client (library) installed (they use MS Windows). If LibreOffice were to require it, I could install them a client library separately, that would not be a huge problem. Even if we would like to do what you suggest, I don't know how, and I don't think it is possible easily. Anyway, if you can find a way to instruct the Darwin (MacOS X) dynamic linker to automagically find a libpq that could be installed just about anywhere on the system (no fixed path) and use that to resolve postgresql-sdbc.uno.dynlib's dependency on libpq, then please show us how. Alternatives are not attractive: * dlopen libpq instead of linking to it, and find it "manually": bleh. So now each user has to set a setting or environmant var or some such to tell us where to find libpq? What's the added value here? * dynamically run otool (the MacOS X equivalent of chrpath/patchelf/...) on ourselves: bleh again. > In any case if there is an 'option' both should work or that option > should be disabled on that platform. Well, AFAIK --with-system-postgresql and --with-libpq-path "works" on MacOS X like on any other platform: it works if libpq.dylib is IN THE SAME PATH on the build machine and on the machine where the binary is run. That is guaranteed under the "package management" systems of GNU/Linux distributions, but is not with fink, MacPorts, etc (even if we'd be OK with requiring those...), neither with the "One-Click installer" for the client lib. However, it can still be useful for custom builds used only internally in an organisation that will install libpq.dylib at a fixed location, so I'd rather we not disable it.
(In reply to comment #26) > So what do you'all consider? > - Releasing 3.5.2 (RC.?) with-- OR without-system-postgresql? > - Or making this even configurable? Is that a lot of work? It is already configurable (at build time). We just fucked up and configured it in a way that is compatible only with MacOX X 10.7 or later. > Anyway, I hope that there will be a working binary soon. > I think some Mac users really appreciate that. > So I'll have to wait until the beginning of April? The builds at http://dev-builds.libreoffice.org/daily/MacOSX-Intel@3-OSX_10.6.0-gcc_4.0.1/libreoffice-3-5/ should be quite usable, and can be considered previews of prereleases of 3.5.2 ;-)
Confirming it works with: libreoffice-3-5~2012-03-12_09.43.12_LibO-Dev_3.5.2rc0_MacOS_x86_install_en-US.dmg Thank you very much. Good luck with this project.
Yay, thanks to all :-))) Alex