[BUGS] psql linked to openssl 0.9.6 _and_ 0.9.7 shared libs
Hi! I've built 7.3.3 under Solaris 2.6 using gcc 2.95.3 and GNU ld. Compilation and the regression tests are all successful. However, I've installed OpenSSL 0.9.7b _and_ have an older 0.9.6 version some programs still depend on (recompiling is on my todo list, though). While the backend is correctly linked to the new 0.9.7b shared libs, > ldd -r ./src/backend/postgres * libssl.so.0.9.7 => /usr/local/ssl/lib/libssl.so.0.9.7 * libcrypto.so.0.9.7 =>/usr/local/ssl/lib/libcrypto.so.0.9.7 libz.so => /usr/local/lib/libz.so libreadline.so.4 => /usr/local/lib/libreadline.so.4 libposix4.so.1 =>/usr/lib/libposix4.so.1 libresolv.so.2 =>/usr/lib/libresolv.so.2 libsocket.so.1 =>/usr/lib/libsocket.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libdl.so.1 =>/usr/lib/libdl.so.1 libm.so.1 => /usr/lib/libm.so.1 libc.so.1 => /usr/lib/libc.so.1 libaio.so.1 => /usr/lib/libaio.so.1 libmp.so.2 =>/usr/lib/libmp.so.2 /usr/platform/SUNW,Ultra-4/lib/libc_psr.so.1 the psql frontend is somehow linked to the _old_ libraries as well as to the new: > ldd -r ./src/bin/psql/psql libpq.so.3 =>/usr/local/pgsql/lib/libpq.so.3 * libssl.so.0.9.7 => /usr/local/ssl/lib/libssl.so.0.9.7 * libcrypto.so.0.9.7 =>/usr/local/ssl/lib/libcrypto.so.0.9.7 libz.so => /usr/local/lib/libz.so libreadline.so.4 => /usr/local/lib/libreadline.so.4 libposix4.so.1 =>/usr/lib/libposix4.so.1 libresolv.so.2 =>/usr/lib/libresolv.so.2 libsocket.so.1 =>/usr/lib/libsocket.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libdl.so.1 =>/usr/lib/libdl.so.1 libm.so.1 => /usr/lib/libm.so.1 libc.so.1 => /usr/lib/libc.so.1 * libssl.so.0.9.6 => /usr/local/ssl/lib/libssl.so.0.9.6 * libcrypto.so.0.9.6 =>/usr/local/ssl/lib/libcrypto.so.0.9.6 libaio.so.1 => /usr/lib/libaio.so.1 libmp.so.2 =>/usr/lib/libmp.so.2 /usr/platform/SUNW,Ultra-4/lib/libc_psr.so.1 * symbol not found: main (/usr/local/ssl/lib/libssl.so.0.9.6) * symbol not found: main (/usr/local/ssl/lib/libcrypto.so.0.9.6) Two questions: * Why is this happening (linked to both versions) ? * and how can I resolve this? Btw, /usr/local/ssl/lib lists as: 2101104 Jul 9 15:01 libcrypto.a 14 Jul 9 15:01 libcrypto.so -> libcrypto.so.0* 18 Jul 9 15:01 libcrypto.so.0 -> libcrypto.so.0.9.7* 1732396 Oct 8 2002 libcrypto.so.0.9.6* 1383287 Jul 9 15:01 libcrypto.so.0.9.7* 317840 Jul 9 15:01 libssl.a 11 Jul 9 15:01 libssl.so -> libssl.so.0* 15 Jul 9 15:01 libssl.so.0 -> libssl.so.0.9.7* 897800 Oct 8 2002 libssl.so.0.9.6* 247251 Jul 9 15:01 libssl.so.0.9.7* Lastly please note that I've built Apache+modssl and OpenSSH on the same machine without problems. Thanks in advance for your help! Regards, Walter ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[BUGS] Error: Panic
Hi folks. I have Postgresql running with Freeside. Yesterday I got this error. Someone can give me some light about the subject, please? POSTGRESQL BUG REPORT TEMPLATE Your name : Javier V. Your email address : [EMAIL PROTECTED] System Configuration - Architecture (example: Intel Pentium) : i586 Operating System (example: Linux 2.0.26 ELF) : Linux RedHat 7.2 PostgreSQL version (example: PostgreSQL-7.3.2): PostgreSQL-7.3.2 Compiler used (example: gcc 2.95.2) : gcc 2.96D Please enter a FULL description of your problem: The data directory seems to be corrupted. This is the error that I got: = = = = = = = = = = = = = = = = = = = = = = = LOG: database system was interrupted at 2003-07-02 16:48:43 PYT LOG: ReadRecord: record with zero length at 0/7F4C3E8 LOG: invalid primary checkpoint record LOG: ReadRecord: record with zero length at 0/7F4C3A8 PANIC: unable to locate a valid checkpoint record LOG: startup process (pid 1081) was terminated by signal 6 LOG: aborting startup due to startup process failure = = = = = = = = = = = = = = = = = = = = = = = _ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[BUGS] Out of memory
Hi, I'm not sure if you know this problem. Create an empty function with 26 parameters: create function test (INTEGER,TEXT,TEXT,TEXT,CHAR(16),CHAR(11), BOOLEAN,BOOLEAN,BOOLEAN,BOOLEAN,BOOLEAN,BOOLEAN, BOOLEAN,BOOLEAN,BOOLEAN,CHAR(2),TEXT,TEXT,TEXT,TEXT, CHAR(5),TEXT,TEXT,TEXT,TEXT,TEXT ) returns integer as ' declare begin return 0; end;' language 'plpgsql'; Call it mistyping the boolean parameters: select test (1,'a','a','a','a','a',1,1,1,1,1,1,1,1,1,'a','a','a','a','a','a','a','a','a','a','a'); Then the system crashes. In /var/log/messages I found: [...] Jul 8 11:21:58 host1 kernel: Out of Memory: Killed process 20586 (postmaster). [...] OS: RH7.3 and RH7.2 PG: 7.3.2 and 7.3.3 ---(end of broadcast)--- TIP 8: explain analyze is your friend
[BUGS] pg_tables view definition incorrect??
version --- PostgreSQL 7.3.2 on i586-pc-linux-gnu, compiled by GCC 2.95.3 (1 row) View "pg_catalog.pg_tables" Column| Type | Modifiers -+-+--- schemaname | name| tablename | name| tableowner | name| hasindexes | boolean | hasrules| boolean | hastriggers | boolean | View definition: SELECT n.nspname AS schemaname, c.relname AS tablename, pg_get_userbyid(c.relowner) AS tableowner, c.relhasindex AS hasindexes, c.relhasrules AS hasrules, (c.reltriggers > 0) AS hastriggers FROM (pg_class c LEFT JOIN pg_namespace n ON ((n.oid = c.relnamespace))) WHERE ((c.relkind = 'r'::"char") OR (c.relkind = 's'::"char")); Given that 'S' => Sequence and 's' => special shouldn't the last condition in the WHERE clause be: c.relkind = 'S'::"char" instead of c.relkind = 's'::"char" ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[BUGS] Precision errors in float8 type casting (as of 7.3.2 and some earlierreleases at least)
I ran into this oddity today and tested it on a few of our PosgreSQL backends (all of which gave the same response): phil=# select 3.85::float4*1; ?column? -- 3.8490463257 (1 row) phil=# select 3.85::float4*1::float8; ?column? -- 3.8490463257 phil=# select (3.85::float4)::float8; float8 -- 3.8490463257 (1 row) (Or substitute 3.85 for any number with something other than 0 to the right of the decimal point, or pull the same values from any table which stores in float4/real format.) Obviously, this is wrong and should return 3.85. We traced this down on an ecom server which was shaving off pennies from some transactions (because we truncate to the hundredths place instead of rounding what we get back from the SQL backend). The newest server we have is 7.3.2, so I haven't tried this on the current 7.3.3 release. phil=# select version(); version - PostgreSQL 7.3.2 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7) (1 row) Phil ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] case sensitivity
Stephan Szabo wrote: On Sun, 6 Jul 2003, Shachar Shemesh wrote: Tom Lane wrote: See also the example and footnote at the end of section 1.1.1 of our documentation: http://www.postgresql.org/docs/view.php?version=7.3&idoc=0&file=sql-syntax.html#SQL-SYNTAX-IDENTIFIERS (not sure why the link to the footnote doesn't work in that version, but the footnote is at the bottom of the page). There has been some talk of providing an alternate mode in which unquoted identifiers are folded per spec, but this seems likely to break enough code that no one has really wanted to do it. My guess is that we will remain intentionally non compliant on this point forever. Just so we are clear what's at stake here. I am trying to perform a migration to PG-SQL for some company. They already support access, MS-SQL and Oracle, and want to support PG-SQL as well. The problem is that the application is MFC, and CRowSet opens the table double-quoting identifiers. The application itself does not. All databases carry all identifiers in allcaps. As some of the ODBC code is Do you mean that the names are always allcaps like FOO? That would certainly show the incompatibility case, yeah. That's how the app doesn't care whether its queries are quoted or not. outside the specific application's control, I cannot tell them to "quote or unquote all statements". This may drop the whole project, which would be a real shame. Documenting this incompatibility is fine as far as it goes, but it does not cover the migration very well. Also something to ponder is this. When I run psql on Debian Sid, and I do: create table "Test" (); select * from table; Do you mean Test here? Yes, I did. Sorry. I'd wonder if you had a test table already defined, I can't reproduce on my 7.3.x box under redhat. Neither can I, now. I guess it was something basic I missed when filing the report. Please ignore. The query runs fine! It seems that PG-SQL 7.3.3. on Linux (at least the Debian version) treats unquoted as case independant. Am I missing something? Why can't I set a "compatibility" flag for the DB? As Tom said, noone's wanted to go through and find all the things that giving an uppercase folding option would break. For example, fairly quickly after simply making the case folding go the other way for identifiers, initdb breaks. It'd probably require someone who had the time and interest in changing it and fixing all the breakage and probably some work from then on making sure that it stays working. I'm willing to give it a go, but I'm going to need a few pointers. I have never done anything with the psql source, and I will need to some help in navigating. Can you please point me to the place where the case comparison is being performed? Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [BUGS] Precision errors in float8 type casting (as of 7.3.2 and
On Wed, 9 Jul 2003, Philip Edelbrock wrote: > phil=# select (3.85::float4)::float8; > float8 > -- > 3.8490463257 > (1 row) > > (Or substitute 3.85 for any number with something other than 0 to the > right of the decimal point, or pull the same values from any table which > stores in float4/real format.) > > Obviously, this is wrong and should return 3.85. We traced this down on I see no obviously about it. Once you've placed a value in a float you are accepting the chance of some precision loss. When we print a float4 we can print it with an amount of precision that generally limits this (although you'll see things like 3.849998 -> 3.5), but once you cast it to a float8 those values are distinguishably different. In theory one could keep the history of the value around to determine a precision, but that doesn't really seem better in general. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [BUGS] Out of memory
On Tue, 8 Jul 2003, Ivan Boscaino wrote: > Hi, > I'm not sure if you know this problem. > > Create an empty function with 26 parameters: > > create function test (INTEGER,TEXT,TEXT,TEXT,CHAR(16),CHAR(11), > BOOLEAN,BOOLEAN,BOOLEAN,BOOLEAN,BOOLEAN,BOOLEAN, > BOOLEAN,BOOLEAN,BOOLEAN,CHAR(2),TEXT,TEXT,TEXT,TEXT, > CHAR(5),TEXT,TEXT,TEXT,TEXT,TEXT ) > returns integer as ' > declare > begin > return 0; > end;' language 'plpgsql'; > > > Call it mistyping the boolean parameters: > > select test > (1,'a','a','a','a','a',1,1,1,1,1,1,1,1,1,'a','a','a','a','a','a','a','a','a','a','a'); > > Then the system crashes. I believe this is fixed in 7.4 (or at least your example does not crash in 7.4) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
