[HACKERS] FETCH from scroll cursor does not return count in libpq PQcmdStatus
Using libpq with pg 8.2.1 on WinXP Pro SP2. After a PQExec with a fetch from a scroll cursor, I only get FETCH from PQcmdStatus, and not FETCH count as described in the 8.2.1 docs. However, PQntuples returns the number of fetched rows. If I replace the FETCH by a MOVE, PQcmdStatus returns MOVE count. The discussion we had on irc #postgresql suggested that this might be a bug, or have we missed some points regarding the use of scroll cursors? ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Windows installer and dlls
I uninstalled postgresql, removed the 5 files mentioned above from system32. When I installed 8.2.0 again, the installer reported that The installer has detected an incompatible version of OpenSSL installed in your system PATH. PostgreSQL requires OpenSSL 0.9.7 or later. If you remove your OpenSSL files (LIBEAY32.DLL and SSLEAY32.DLL) the installer will install the new version automatically.. However, during the second installation, none of the 5 files mentioned above were reinstalled in system32, only in the postgresql bin directory, as during the first installation. Is the report of the missing libeay32 and ssleay32 a superfluous leftover from the previous versions when these files were installed in system32? Are you sure they are not present in some *other* directory on your system that's in the PATH? //Magnus You're right. After they were removed from both C:\windows and C:\windows\system32 the installer did no longer report incompatible OpenSSL version. By the way: E.1.3.15. Win32 Port Allow MSVC to compile the PostgreSQL server (Magnus, Hiroshi Saito). Does this mean that the precompiled windows version of postgresql will be compiled by MSVC (I assume you can use the free 2005 express edition), or still by MinGW. I guess this will affect which compiler one should use for compilation of C-functions? Thanks, KP ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] Windows installer and dlls
Installing postgresql 8.2.0 on Windows XP Pro SP2 using the msi installer dated 2006-12-04, with libeay32.dll and ssleay32.dll (both dated 2005-07-06) (and libiconv-2.dll, libintl-2.dll, and libpq.dll) from a previous installation (of version 8.0.5) already present in c:\windows\system32. These files in system32 did not appear to be updated during the 8.2.0 installation. Instead new files were placed in the postgresql bin directory: new versions of libeay32, ssleay32, and libpq, the same version as the present of libiconv-2 (2003-01-31), and, surprisingly, a libintl-2 with an older date (2003-02-01) than the file already present in system32 (2004-04-27). Is the libintl-2 supposed to be downgraded to a previous version? I uninstalled postgresql, removed the 5 files mentioned above from system32. When I installed 8.2.0 again, the installer reported that The installer has detected an incompatible version of OpenSSL installed in your system PATH. PostgreSQL requires OpenSSL 0.9.7 or later. If you remove your OpenSSL files (LIBEAY32.DLL and SSLEAY32.DLL) the installer will install the new version automatically.. However, during the second installation, none of the 5 files mentioned above were reinstalled in system32, only in the postgresql bin directory, as during the first installation. Is the report of the missing libeay32 and ssleay32 a superfluous leftover from the previous versions when these files were installed in system32? ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] SSL client crt verification
Server: 7.4.8 on Red Hat EL4. Client psql 8.0.3 on WinXP. Using a test server.crt and server.key, as described in 8.0 docs 16.8, I can activate SSL encryption (WinXP 8.0.3 psql reports SSL Connection at connect), and as expected, the server log reports that root.crt is not found. If I copy server.crt to root.crt and start up server again, the missing root.crt message disappears. But I can still connect with psql with no postgresql.crt on client (docs 27.13). Apparently, the root.crt, which in this case is a copy of server.crt, is not interpreted as a CA crt, but how does the server know? Isn't a CA cert just a self signed crt? Why is there not a warning that client authentication will not take place, when it apparently does not? Does the server only check that a root.crt file is present, and not that is contains valid information? You really need a separate root CA cert and server key. The server key should be signed by the root CA, which is self-signed. The root CA private key should be kept secure somewhere else--the database server doesn't need access to it. I just went though the whole exercise of creating a CA and setting up an app for client cert authentication, so I am reasonably sure the above is your problem. For client auth to work, you need: * Root CA certificate available to both client and server * Server cert signed by root CA, with CN=server hostname * Client cert signed by root CA, available to client to present to server. -Doug Thanks for your comments. I seem to get SSL client authentication to work with a 8.0.3 server on win32 (a client crt needed for connection), but still not with the 7.4.8 server on Red Hat EL4, even with separate root CA subject and server.crt subject, as you suggest. Interestingly, version 8 docs (16.8) mention the root.crt file needed for client auth, while 7.4 docs do not mention it. Similarly, the 27.13 section on libpq SSL support in 8 docs is not there in the 7.4 docs. Maybe my problem is that 7.4.8 doesn't support client authentication? However, that doesn't fit with the fact that the 7.4.8 server log reports that it will not verify client certificates if the root.crt file is missing in the server data directory. Have I missed some points regarding linux or 7.4 SSL setup? From docs I understand that I only have to set SSL = true in postgresql.conf to switch it on (in addition to providing the crt and key files). KPL ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] SSL client crt verification
To the last sentence in my last post Re: SSL client crt verification: From docs I understand that I only have to set SSL = true in postgresql.conf to switch it on (in addition to providing the crt and key files). I should have added: ...and using hostssl in pg_hba.conf (although host also works on my 8.0.3 server, presumably because of the default sslmode=prefer in libpq). KPL ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] SSL client crt verification
Tried doc search, pgsql-general and #postgresql. Server: 7.4.8 on Red Hat EL4. Client psql 8.0.3 on WinXP. Using a test server.crt and server.key, as described in 8.0 docs 16.8, I can activate SSL encryption (WinXP 8.0.3 psql reports SSL Connection at connect), and as expected, the server log reports that root.crt is not found. If I copy server.crt to root.crt and start up server again, the missing root.crt message disappears. But I can still connect with psql with no postgresql.crt on client (docs 27.13). Apparently, the root.crt, which in this case is a copy of server.crt, is not interpreted as a CA crt, but how does the server know? Isn't a CA cert just a self signed crt? Why is there not a warning that client authentication will not take place, when it apparently does not? Does the server only check that a root.crt file is present, and not that is contains valid information? Comments appreciated KPL ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
