Re: [HACKERS] Favorable i--)
On Saturday, November 27, 2010, Nikhil Sontakke nikkh...@gmail.com wrote: Hi, a very good business company, I suggest you go to see: mobiles3gs.com, and now all of products enjoy great discount, saving time and money. h--) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Segmentation fault using digest from pg_crypto
Marko Kreen [EMAIL PROTECTED] writes: On 8/24/07, Manuel Sugawara [EMAIL PROTECTED] wrote: Manuel Sugawara [EMAIL PROTECTED] writes: I have a simple query that uses digest(data, 'sha1') and consistently crashes the backend The problem is with null arguments: ciencias=# select digest(null, 'sha1'); In 8.0 the pgcrypto functions were non-strict and checked for NULLs. In 8.1 they were made STRICT. In 8.2 the NULL check were removed from code. Not an smart move IMHO, I didn't create the function, it was created as part of my upgrade process. May I suggest to put back the check?. Regards, Manuel. ---(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] Segmentation fault using digest from pg_crypto
Tom Lane [EMAIL PROTECTED] writes: Manuel Sugawara [EMAIL PROTECTED] writes: Marko Kreen [EMAIL PROTECTED] writes: In 8.0 the pgcrypto functions were non-strict and checked for NULLs. In 8.1 they were made STRICT. In 8.2 the NULL check were removed from code. Not an smart move IMHO, I didn't create the function, it was created as part of my upgrade process. May I suggest to put back the check?. That's the standard way of doing things in C functions (ie, rely on STRICT markings) and I see nothing wrong with it. If you were using an upgrade process that failed to incorporate version-to-version changes in the definitions of contrib functions, this is hardly going to be the only problem you encounter. I was under the impression that the standar procedure for upgrading was to read the release notes searching for this kind of gotchas. I've reviewed (again) the release notes for 8.1 and 8.2 and didn't find anything related but maybe I'm not searching hard enough. If something is not going a work (or is going a work in a different way) in some version after loading a shot form a previous one I think it should be documented or some kind of backwards compatibility mechanism should be provided. Regards, Manuel. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] Segmentation fault using digest from pg_crypto
Hi, I have a simple query that uses digest(data, 'sha1') and consistently crashes the backend (tested in two different machines): ciencias=# select version(); version - PostgreSQL 8.2.4 on x86_64-redhat-linux-gnu, compiled by GCC gcc (GCC) 3.4.6 20060404 (Red Hat 3.4.6-8) (1 row) ciencias=# select version(); version PostgreSQL 8.2.4 on i686-redhat-linux-gnu, compiled by GCC gcc (GCC) 4.1.1 20070105 (Red Hat 4.1.1-51) (1 fila) with segmentation fault. Backtrace follows: -bash-3.1$ gdb `which postgres` ./data/core.7428 GNU gdb Red Hat Linux (6.5-15.fc6rh) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-redhat-linux-gnu...Using host libthread_db library /lib/libthread_db.so.1. warning: Can't read pathname for load map: Error de entrada/salida. Reading symbols from /lib/libcrypt.so.1...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libm.so.6...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /lib/libnss_files.so.2...done. Loaded symbols for /lib/libnss_files.so.2 Reading symbols from /usr/lib/gconv/ISO8859-1.so...done. Loaded symbols for /usr/lib/gconv/ISO8859-1.so Reading symbols from /usr/lib/pgsql/pgcrypto.so...Reading symbols from /usr/lib/debug/usr/lib/pgsql/pgcrypto.so.debug...done. done. Loaded symbols for /usr/lib/pgsql/pgcrypto.so Reading symbols from /usr/lib/libz.so.1...done. Loaded symbols for /usr/lib/libz.so.1 Core was generated by `postgres: masm ciencias [local] SELECT '. Program terminated with signal 11, Segmentation fault. #0 pg_detoast_datum (datum=0x0) at fmgr.c:1964 1964if (VARATT_IS_EXTENDED(datum)) (gdb) bt #0 pg_detoast_datum (datum=0x0) at fmgr.c:1964 #1 0x00124c9e in pg_digest (fcinfo=0xbf9ba174) at pgcrypto.c:73 #2 0x0815127c in ExecMakeFunctionResultNoSets (fcache=0x8fa84f8, econtext=0x8fa83d8, isNull=0x8fad282 , isDone=0x8fad2e0) at execQual.c:1330 #3 0x0814ce57 in ExecProject (projInfo=0x8fad290, isDone=0xbf9ba438) at execQual.c:4119 #4 0x08159d1c in ExecHashJoin (node=0x8fa8350) at nodeHashjoin.c:270 #5 0x0814c55d in ExecProcNode (node=0x8fa8350) at execProcnode.c:390 #6 0x0814b87b in ExecutorRun (queryDesc=0x8fa7ae0, direction=ForwardScanDirection, count=0) at execMain.c:1082 #7 0x081d5300 in PortalRunSelect (portal=0x8f85530, forward=value optimized out, count=0, dest=0x8f97920) at pquery.c:831 #8 0x081d6269 in PortalRun (portal=0x8f85530, count=2147483647, dest=0x8f97920, altdest=0x8f97920, completionTag=0xbf9ba688 ) at pquery.c:684 #9 0x081d1f40 in exec_simple_query ( query_string=0x8f64420 select a.id, a.persona, digest(to_char(fecha_nacimiento, 'DDMM'), 'sha1') from auth.credential c join auth.agent a on (a.id = c.agent) join persona.persona p on (p.id = a.persona) where now() betw...) at postgres.c:939 #10 0x081d3517 in PostgresMain (argc=4, argv=value optimized out, username=0x8efc540 masm) at postgres.c:3424 #11 0x081aaf0e in ServerLoop () at postmaster.c:2931 #12 0x081abd0a in PostmasterMain (argc=3, argv=0x8ef95b8) at postmaster.c:963 #13 0x0816b3d0 in main (argc=3, argv=Cannot access memory at address 0x9 ) at main.c:188 (gdb) Please letme know if there is more information I can supply. Regards, Manuel. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Segmentation fault using digest from pg_crypto
Manuel Sugawara [EMAIL PROTECTED] writes: Hi, I have a simple query that uses digest(data, 'sha1') and consistently crashes the backend The problem is with null arguments: ciencias=# select digest(null, 'sha1'); el servidor ha cerrado la conexión inesperadamente, probablemente porque terminó de manera anormal antes o durante el procesamiento de la petición. La conexión al servidor se ha perdido. Intentando reiniciar: falló. ! Regards, Manuel. ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[HACKERS] Query returning tuples that does not satisfy the WHERE clause
Hi all, I'm running PostgreSQL v 8.1.4 and found a query that returns tuples that does not satisfy the WHERE clause, the query is: select * into errores_20071 from ( select r.id, r.trayectoria_id, r.grupo_id, regacd.insc_registra_grupo(trayectoria_id, grupo_id, true, false, true) as error from regacd.registro r join regacd.grupo g on (g.id = r.grupo_id) where g.año_semestre = 20071 and g.tipo_id = 'a') x where error is not null; A self-contained database schema is here: schema-registro.sql Description: Binary data Unfortunately I cannot post the data set but I'm willing to give access to my machine to test the problem. While trying to create a self contained test case I found that the query returns the correct answer before analyzing: QUERY PLAN Nested Loop (cost=41.61..31193.44 rows=36 width=12) - Index Scan using AsignaturClaveGrupoÚnicaPorAñoSemestre2 on grupo g (cost=0.00..14.03 rows=3 width=4) Index Cond: ((año_semestre = 20071) AND (tipo_id = 'a'::char)) - Bitmap Heap Scan on registro r (cost=41.61..10305.22 rows=7031 width=12) Recheck Cond: (outer.id = r.grupo_id) Filter: (insc_registra_grupo(trayectoria_id, grupo_id, true, false, true) IS NOT NULL) - Bitmap Index Scan on registro_grupo (cost=0.00..41.61 rows=7031 width=0) Index Cond: (outer.id = r.grupo_id) (8 filas) but does not after I run analyze: QUERY PLAN Hash Join (cost=1166.75..44109.74 rows=34184 width=12) Hash Cond: (outer.grupo_id = inner.id) - Seq Scan on registro r (cost=0.00..28538.85 rows=1397684 width=12) Filter: (insc_registra_grupo(trayectoria_id, grupo_id, true, false, true) IS NOT NULL) - Hash (cost=1159.54..1159.54 rows=2883 width=4) - Bitmap Heap Scan on grupo g (cost=31.30..1159.54 rows=2883 width=4) Recheck Cond: ((año_semestre = 20071) AND (tipo_id = 'a'::char)) - Bitmap Index Scan on AsignaturClaveGrupoÚnicaPorAñoSemestre2 (cost=0.00..31.30 rows=2883 width=0) Index Cond: ((año_semestre = 20071) AND (tipo_id = 'a'::char)) (9 filas) Using the second plan the query is returning tuples where año_semestre 20071 Any help will be appreciated. Best regards, Manuel. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Query returning tuples that does not satisfy the WHERE clause
Tom Lane [EMAIL PROTECTED] writes: You seem to have worse problems than that, because as given the insc_registra_grupo function never returns non-NULL Actually the function (and the database) is quite complex and was trimed just to test the problem. I suspect pilot error --- perhaps looking at the wrong schema or some such? I don't think so, search_path has its default value and also I'm able to reproduce it in a fresh cluster (tried 3 different machines to discard hardware problems). Regards, Manuel. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] to_char and i18n
Now that Oracle supports i18n dependant behavior in its to_char formatting functions (at least for its 10g release) I was wondering if a patch to support this in PostgreSQL will get accepted. I was hoping to work on this now that I have some spare time. Regards, Manuel. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] to_char and i18n
Qingqing Zhou [EMAIL PROTECTED] writes: Can you give a small introduction of i18n and what's your plan in PostgreSQL? i18n == Internationalization (maybe I should say l10n == localization). This means that to_char functions might lead to different results depending on the i18n settings. For instance, nowadays, select to_char(now(), 'dd-mon-yy') returns 21-dec-05 regardless of the i18n settings. This should lead 21-dic-05 in the es_MX localization. This also applies to the concurrency symbol, thousand separator, etc. (Some time ago I proposed an--incomplete--patch and it was rejectd by Karel arguing that to_char functions should behave *exactly* the same way that they do in Oracle.) Regards, Manuel. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] to_char and i18n
Tom Lane [EMAIL PROTECTED] writes: I thought to_char already had i18n behavior. What exactly are you thinking of changing? The modifiers that are suitable to localize. Month and day names comes to mind and maybe others, I'm not sure what the state of the code is, but I can say that, at least, the 'month' and 'day' modifiers does not behave in a localized way. Regards, Manuel. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] to_char and i18n
Tom Lane [EMAIL PROTECTED] writes: Can we spell the names differently but keep to the same field widths? I can see where it might cause problems to change the widths --- other than that, no objection. Quite impossible. But if someone is relaying in the current behavior of to_char she might set lc_time accordingly as this parameter is not used in the code, AFAIK Regards, Manuel. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] to_char and i18n
Gavin Sherry [EMAIL PROTECTED] writes: There's some functionality in 10g which PostgreSQL does not have: Good to know. I'm not an Oracle expert, actually I knew this reading an article in a past issue of the Oracle's magazine about i18n; essentially they were talking about how easy was for an Oracle database to get i18n as each parameter in the to_char functions will behave accordingly to the i18n settings. Regards, Manuel. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] localization problem (and solution)
Here is a test case for a previously reported bug (see http://archives.postgresql.org/pgsql-general/2005-11/msg01235.php): initdb using es_MX.ISO-8859-1, start postgres using es_MX.UTF-8 and execute: create procedural language plperl; create or replace function foo() returns int as 'return 1' language 'plperl'; create table persona (nombre text check (nombre ~ '^[[:upper:]][[:lower:]]*([-''. [:alpha:]]+)?$'::text)); copy persona (nombre) from stdin; José \. It will error out saying: ERROR: new row for relation persona violates check constraint persona_nombre_check CONTEXT: COPY persona, line 1: José Commenting the creation of the plperl function (or moving it after the copy command) this script runs without errors. Also applying this patch solves the problem: *** src/backend/access/transam/xlog.c~ 2005-11-22 12:23:05.0 -0600 --- src/backend/access/transam/xlog.c 2005-12-19 20:34:22.0 -0600 *** *** 3626,3631 --- 3626,3632 which is not recognized by setlocale()., ControlFile-lc_collate), errhint(It looks like you need to initdb or install locale support.))); + setenv(LC_COLLATE, ControlFile-lc_collate, 1); if (setlocale(LC_CTYPE, ControlFile-lc_ctype) == NULL) ereport(FATAL, (errmsg(database files are incompatible with operating system), *** *** 3633,3638 --- 3634,3640 which is not recognized by setlocale()., ControlFile-lc_ctype), errhint(It looks like you need to initdb or install locale support.))); + setenv(LC_CTYPE, ControlFile-lc_ctype, 1); /* Make the fixed locale settings visible as GUC variables, too */ SetConfigOption(lc_collate, ControlFile-lc_collate, Some fprintf's around the regex code shows that someone is changing the localization parameters by those found in the enviroment, at least for the LC_CTYPE and LC_COLLATE categories, and plperl seems to be the culprit. Needless to say that this bug might lead to index corruption beside other problems. It also explains some very wired (and very difficult to reproduce) anomalies I have seen. Regards, Manuel. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] localization problem (and solution)
Tom Lane [EMAIL PROTECTED] writes: (Your proposed fix seems entirely useless ... While there are reasons to argue that's Perl fault, IMO, an environment that reflects the current state of the host program is a good compromise, and behave environment-consistent is also a good compromise for libperl (I think some applications of libperl will get really upset if this compromise is broken by the library.) Regards, Manuel. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] problems with locale settings
Hi, Starting postgres as part as of the normal boot process of my db server (up2date FC3) leads to an ``unusable'' database since it does not set the locale properly. For instnace: test=# select 'í' ~ '[[:lower:]]'; ?column? -- f (1 fila) However, starting postgres as $ LANG=es_MX pg_ctl -D ~/data start leads the desired result: test=# select 'í' ~ '[[:lower:]]'; ?column? -- t (1 fila) There's something wired here since my (fast) reading of the sources makes me thing that postgres should honor the pg_control's lc_type locale settings. BTW, I couldn't reproduce this in another machine using pg 8.0.1. Regards, Manuel. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] default enconding
Hi, I have found what I thing is a quite annoying behaviour of Postgres (psql). When you type (and ask for complation) for some string that has some characters not in the ASCII encoding it requires a double quote on it, however if you don't put those double quotes around it, you can still execute the query. So what about changing the behaviour to either don't accept characters with the 8 bit set or accept by default strings in the iso-8859-1 encoding instead of ASCII endoding by default. Regards, Manuel. ---(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
Re: [HACKERS] default enconding
Tom Lane [EMAIL PROTECTED] writes: ... in other words, it doesn't require the double quotes. I don't see the value of being more restrictive. Why is this annoying? Note also that using iso-8859-1 is not more restrictive, but just the opposite. Using iso-8859-1 will be useful also for English users since some words in use in the English language use characters not in the ASCII encoding, resumé for instance. Regards, Manuel. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] default enconding
Tom Lane [EMAIL PROTECTED] writes: Manuel Sugawara [EMAIL PROTECTED] writes: Hi, I have found what I thing is a quite annoying behaviour of Postgres (psql). When you type (and ask for complation) for some string that has some characters not in the ASCII encoding it requires a double quote on it, however if you don't put those double quotes around it, you can still execute the query. ... in other words, it doesn't require the double quotes. I don't see the value of being more restrictive. Why is this annoying? It's because you can't complete without the double quote, so, select something.fotab doesn't complete if you have only foó as the only completion whereas select something .fo does. Regards, Manuel. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] default enconding
Tatsuo Ishii [EMAIL PROTECTED] writes: I think we need to fix that as well. I do agreee, however, we have to start somewhere. Regards, Manuel. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Spanish list hosting request
Dear Hackers, We are having really hard times with the PostgreSQL spanish list hosted here in México, mainly because the lack of administration. That's really sad since we are a well established and growing community. So, we would like to know if it's possible that the list is hosted by postgresql.org. We can do it of course, but we want an stable and long term solution to our list administration problems, and I can't think in a better option. Please let us know if it's possible and if it is what's needed to accomplish the change. Best Regards, Manuel. ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] pg_dump oid representation
I did the es translation of pg_dump and while looking at the code I found that in several places the char * representation of Oid's is used instead of the oid itself. Any one knows why is done this way? Regards, Manuel. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] cvs build failure
Larry Rosenman [EMAIL PROTECTED] writes: what version of bison are you using? I believe we require 1.875 these days. It would be nice to be able to say --without-ecpg at configure time. Ecpg is the only part of pg that requires this version of bison and and is not a core part of the project, or is it? Regards, Manuel. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] beta1 packaged
Guys, postgresql7.3b1 does not build :-(, seems like a missing multibyte directory ' | make[4]: Entering directory |`/home/masm/download/postgresql-7.3b1/src/backend/utils/time' | gcc -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include | -c -o tqual.o tqual.c | /usr/bin/ld -r -o SUBSYS.o tqual.o | make[4]: Leaving directory |`/home/masm/download/postgresql-7.3b1/src/backend/utils/time' | make -C mb SUBSYS.o | make: Entering an unknown directory | make: *** mb: No such file or directory. Stop. | make: Leaving an unknown directory | make[3]: *** [mb-recursive] Error 2 | make[3]: Leaving directory `/home/masm/download/postgresql-7.3b1/src/backend/utils' | make[2]: *** [utils-recursive] Error 2 | make[2]: Leaving directory `/home/masm/download/postgresql-7.3b1/src/backend' | make[1]: *** [all] Error 2 | make[1]: Leaving directory `/home/masm/download/postgresql-7.3b1/src' | make: *** [all] Error 2 ` or I'm missing something? Regards, Manuel. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] beta1 packaged
Tom Lane [EMAIL PROTECTED] writes: So it would seem. The utils/mb directory is certainly there in the full tarball that I pulled from ftp.us.postgresql.org this morning. How did you acquire your source tree, exactly? The file is postgresql-base-7.3b1.tar.gz from ftp://ftp.postgresql.org/pub/source/v7.3beta/ may be I need postgresql-7.3b1.tar.gz? Regards, Manuel. -- No es que no puedan hallar la solución: es que no ven el problema. G.K. Chesterson ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] beta1 packaged
Marc G. Fournier [EMAIL PROTECTED] writes: You need either the 7.3b1.tar.gz (which is everything), or you need to get all the various -*- parts (which are more manageable) Oh, well. Thanks Regards, Manuel. -- No es que no puedan hallar la solución: es que no ven el problema. G.K. Chesterson ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] beta1 packaged
Bruce Momjian [EMAIL PROTECTED] writes: You need either the 7.3b1.tar.gz (which is everything), or you need to get all the various -*- parts (which are more manageable) I am confused. Are you saying the base file isn't compilable? My idea was that it is. Regards, Manuel. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Redhat 7.3 time manipulation bug
This thread is getting pretty annoying rather than constructive. By the mean time I can see the users of many db's running under linux loudly complaining. As a user of both products (glibc and postgres), I would like to see a good compromise in both sides. For instance: postgreSQL will implement it's own time engine in one or to releases (In a few months I can do it if no one else volunteers) and glibc will revert this change for one or two releases (I can do it right now). That way everyone will be happy; particularly me and many others using glibc and postgres. Regards, Manuel. ---(end of broadcast)--- TIP 3: 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] Redhat 7.3 time manipulation bug
Lamar Owen [EMAIL PROTECTED] writes: On Monday 20 May 2002 08:08 pm, Manuel Sugawara wrote: Where would we go to ferret out the source of this bug? More to the point: we need a test case in C that could expose this as a glibc bug. Seems like mktime(3) is having problems with dates before the epoch. Attached is the a program to test this. The glibc source is now downloading I will try to hunt down this bug but not until the next week. It's not a bug. At least not according to the ISO C standard. See http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap04.html#tag_04_14 for the definition of 'Seconds Since the Epoch', then cross-reference to the man page of mktime. I see. This behavior is consistent with the fact that mktime is supposed to return -1 on error, but then is broken in every other Unix implementation that I know. Any other workaround than downgrade or install FreeBSD? Regards, Manuel. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Redhat 7.3 time manipulation bug
Trond Eivind Glomsrød [EMAIL PROTECTED] writes: Relying on nonstandardized/nondocumented behaviour is a program bug, not a glibc bug. The question is: how this thing didn't show up before? ISTM that someone is not doing his work correctly. PostgreSQL needs fixing. Arguably, however, right now is *a lot easier* to fix glibc, and it's really needed for production systems using postgreSQL and working on RedHat. But redhat users doesn't matter, the most important thing is *strict* conformace to standars, right? Since we ship both, we're looking at it, but glibc is not the ^^^ The sad true is: you only answered when the 'Complain to Red Hat' statement appeared, not a single word before and not a single word when the bug report were closed. I'm really disappointed. The nice thing is: glibc is free software and we don't have to wait or relay on some of the redhat staff members (thanks god) for this to get fixed or say: for the standard to get extended again. The patch to glibc is pretty straightforward and attached. Regards, Manuel. --- glibc-2.2.5/time/mktime.c.org Tue May 21 11:37:06 2002 +++ glibc-2.2.5/time/mktime.c Tue May 21 11:39:28 2002 @@ -259,11 +259,13 @@ int sec_requested = sec; +#if 0 /* Only years after 1970 are defined. If year is 69, it might still be representable due to timezone differnces. */ if (year 69) return -1; +#endif #if LEAP_SECONDS_POSSIBLE /* Handle out-of-range seconds specially, ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Redhat 7.3 time manipulation bug
Lamar Owen [EMAIL PROTECTED] writes: Filed on Red Hat's Bugzilla system as bug# 65227, as I can reliably reporoduce this bug here, and PostgreSQL 7.2.1 on Red Hat 6.2 on SPARC does not exhibit the bug. Thanks for filling that report. I couldn't remember what had forgotten ;-) Regards, Manuel. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Redhat 7.3 time manipulation bug
Lamar Owen [EMAIL PROTECTED] writes:
Where would we go to ferret out the source of this bug? More to the
point: we need a test case in C that could expose this as a glibc
bug.
Seems like mktime(3) is having problems with dates before the
epoch. Attached is the a program to test this. The glibc source is now
downloading I will try to hunt down this bug but not until the next
week.
Regards,
Manuel.
#include stdio.h
#include time.h
int main(int argc, char *argv[])
{
struct tm fails;
fails.tm_sec = 0;
fails.tm_min = 0;
fails.tm_hour = 0;
fails.tm_hour = 0;
fails.tm_isdst = -1;
fails.tm_year = 69;
fails.tm_mon = 11;
fails.tm_mday = 30;
if ( mktime(fails) != -151200L ) {
printf(mktime is broken\n);
return 1;
}
printf(mktime test passed\n);
return 0;
}
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Redhat 7.3 time manipulation bug
Hi,
Something is pretty broken in redhat 7.3 but I'm not sure what and I
don't have time to dig further
masm@test=# select cast('1967-04-18' as timestamptz);
timestamptz
1967-04-17 18:00:00-06
(1 row)
masm@test=# select cast(cast('1967-04-18' as date) as timestamp);
ERROR: Unable to convert date to tm
masm@test=#
Both cases works correctly in Redhat 7.2. Sorry if this is not the
correct forum however an alert is nice for people planning an Redhat
upgrade. I hope to see pretty soon an update since I don't want to
downgrade my server.
Regards,
Manuel.
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] regexp character class locale awareness patch
Alvaro Herrera [EMAIL PROTECTED] writes: En 17 Apr 2002 22:53:32 -0600 Manuel Sugawara [EMAIL PROTECTED] escribió: Bruce Momjian [EMAIL PROTECTED] writes: Tatsuo Ishii wrote: I miss that case :-(. Here is the pached patch. Regards, Manuel. I also suggest that cclass_init() is called only if the locale is not C. OK, patch on hold while this is addressed. Here is a patch which addresses Tatsuo's concerns (it does return an static struct instead of constructing it). Is there a reason to use instead of NULL in the multis member of that static struct? Yes, read the code. Regards, Manuel. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] regexp character class locale awareness patch
Bruce Momjian [EMAIL PROTECTED] writes:
Alvaro Herrera wrote:
En Tue, 16 Apr 2002 19:21:50 -0400 (EDT)
Bruce Momjian [EMAIL PROTECTED] escribi?:
Here is a patch based on this discussion.
I still think the xdigit class could be handled the same way the digit
class is (by enumeration rather than using the isxdigit function). That
saves you a cicle, and I don't think there's any loss.
In fact, I will email you when I apply the original patch.
I miss that case :-(. Here is the pached patch.
Regards,
Manuel.
Index: src/backend/regex/regcomp.c
===
RCS file: /cvsroot/pgsql/src/backend/regex/regcomp.c,v
retrieving revision 1.28
diff -c -r1.28 regcomp.c
*** src/backend/regex/regcomp.c 28 Oct 2001 06:25:49 - 1.28
--- src/backend/regex/regcomp.c 16 Apr 2002 23:12:38 -
***
*** 47,53
#include regex/regex.h
#include regex/utils.h
#include regex/regex2.h
! #include regex/cclass.h
#include regex/cname.h
/*
--- 47,60
#include regex/regex.h
#include regex/utils.h
#include regex/regex2.h
! struct cclass
! {
! char *name;
! char *chars;
! char *multis;
! };
! static struct cclass* cclasses = NULL;
! static struct cclass* cclass_init(void);
#include regex/cname.h
/*
***
*** 174,179
--- 181,189
pg_wchar *wcp;
#endif
+ if ( cclasses == NULL )
+ cclasses = cclass_init();
+
#ifdef REDEBUG
#define GOODFLAGS(f) (f)
#else
***
*** 884,890
struct cclass *cp;
size_t len;
char *u;
! charc;
while (MORE() pg_isalpha(PEEK()))
NEXT();
--- 894,900
struct cclass *cp;
size_t len;
char *u;
! unsigned char c;
while (MORE() pg_isalpha(PEEK()))
NEXT();
***
*** 905,911
u = cp-chars;
while ((c = *u++) != '\0')
! CHadd(cs, c);
for (u = cp-multis; *u != '\0'; u += strlen(u) + 1)
MCadd(p, cs, u);
}
--- 915,921
u = cp-chars;
while ((c = *u++) != '\0')
! CHadd(cs, c);
for (u = cp-multis; *u != '\0'; u += strlen(u) + 1)
MCadd(p, cs, u);
}
***
*** 1715,1718
--- 1725,1788
#else
return (islower((unsigned char) c));
#endif
+ }
+
+ static struct cclass *
+ cclass_init(void)
+ {
+ struct cclass *cp = NULL;
+ struct cclass *classes = NULL;
+ struct cclass_factory
+ {
+ char *name;
+ int (*func)(int);
+ char *chars;
+ } cclass_factories [] =
+ {
+ { alnum, isalnum, NULL },
+ { alpha, isalpha, NULL },
+ { blank, NULL, \t },
+ { cntrl, iscntrl, NULL },
+ { digit, NULL, 0123456789 },
+ { graph, isgraph, NULL },
+ { lower, islower, NULL },
+ { print, isprint, NULL },
+ { punct, ispunct, NULL },
+ { space, NULL, \t\n\v\f\r },
+ { upper, isupper, NULL },
+ { xdigit,NULL, abcdefABCDEF0123456789 },
+ { NULL, NULL, NULL }
+ };
+ struct cclass_factory *cf = NULL;
+
+ classes = malloc(sizeof(struct cclass) * (sizeof(cclass_factories) /
+sizeof(struct cclass_factory)));
+ if (classes == NULL)
+ elog(ERROR,cclass_init: out of memory);
+
+ cp = classes;
+ for(cf = cclass_factories; cf-name != NULL; cf++)
+ {
+ cp-name = strdup(cf-name);
+ if ( cf-chars )
+ cp-chars = strdup(cf-chars);
+ else
+ {
+ int x = 0, y = 0;
+ cp-chars = malloc(sizeof(char) * 256);
+ if (cp-chars == NULL)
+ elog(ERROR,cclass_init: out of memory);
+ for (x = 0; x 256; x++)
+ {
+ if((cf-func)(x))
+ *(cp-chars + y++) = x;
+ }
+ *(cp-chars + y) = '\0';
+ }
+ cp-multis = ;
+ cp++;
+ }
+ cp-name = cp-chars = NULL;
+ cp-multis = ;
+
+ return classes;
}
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] regexp character class locale awareness patch
Bruce Momjian [EMAIL PROTECTED] writes:
Tatsuo Ishii wrote:
I miss that case :-(. Here is the pached patch.
Regards,
Manuel.
I also suggest that cclass_init() is called only if the locale is not
C.
OK, patch on hold while this is addressed.
Here is a patch which addresses Tatsuo's concerns (it does return an
static struct instead of constructing it).
Regards,
Manuel.
--- src/backend/regex/regcomp.c.org Wed Apr 17 21:25:25 2002
+++ src/backend/regex/regcomp.c Wed Apr 17 21:38:25 2002
@@ -47,8 +47,17 @@
#include regex/regex.h
#include regex/utils.h
#include regex/regex2.h
-#include regex/cclass.h
#include regex/cname.h
+#include locale.h
+
+struct cclass
+{
+char *name;
+char *chars;
+char *multis;
+};
+static struct cclass* cclasses = NULL;
+static struct cclass* cclass_init(void);
/*
* parse structure, passed up and down to avoid global variables and
@@ -174,6 +183,9 @@
pg_wchar *wcp;
#endif
+if ( cclasses == NULL )
+cclasses = cclass_init();
+
#ifdef REDEBUG
#define GOODFLAGS(f) (f)
#else
@@ -884,7 +896,7 @@
struct cclass *cp;
size_t len;
char *u;
- char c;
+ unsigned char c;
while (MORE() pg_isalpha(PEEK()))
NEXT();
@@ -1716,3 +1728,81 @@
return (islower((unsigned char) c));
#endif
}
+
+static struct cclass *
+cclass_init(void)
+{
+static struct cclass cclasses_C[] = {
+{ alnum, ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789, },
+{ alpha, ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz, },
+{ blank, \t, },
+{ cntrl, \007\b\t\n\v\f\r\1\2\3\4\5\6\16\17\20\21\22\23\24\25\26\27\30\31\32\33\34\35\36\37\177, },
+{ digit, 0123456789, },
+{ graph, ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789!\#$%'()*+,-./:;=?@[\\]^_`{|}~, },
+{ lower, abcdefghijklmnopqrstuvwxyz, },
+{ print, ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789!\#$%'()*+,-./:;=?@[\\]^_`{|}~ , },
+{ punct, !\#$%'()*+,-./:;=?@[\\]^_`{|}~, },
+{ space, \t\n\v\f\r , },
+{ upper, ABCDEFGHIJKLMNOPQRSTUVWXYZ, },
+{ xdigit, 0123456789ABCDEFabcdef, },
+{ NULL, NULL, }
+};
+struct cclass *cp = NULL;
+struct cclass *classes = NULL;
+struct cclass_factory
+{
+char *name;
+int (*func)(int);
+char *chars;
+} cclass_factories [] =
+{
+{ alnum, isalnum, NULL },
+{ alpha, isalpha, NULL },
+{ blank, NULL, \t },
+{ cntrl, iscntrl, NULL },
+{ digit, NULL, 0123456789 },
+{ graph, isgraph, NULL },
+{ lower, islower, NULL },
+{ print, isprint, NULL },
+{ punct, ispunct, NULL },
+{ space, NULL, \t\n\v\f\r },
+{ upper, isupper, NULL },
+{ xdigit, NULL, 0123456789ABCDEFabcdef },
+{ NULL, NULL, NULL }
+};
+struct cclass_factory *cf = NULL;
+
+if ( strcmp( setlocale( LC_CTYPE, NULL ), C ) == 0 )
+return cclasses_C;
+
+classes = malloc(sizeof(struct cclass) * (sizeof(cclass_factories) / sizeof(struct cclass_factory)));
+if (classes == NULL)
+elog(ERROR,cclass_init: out of memory);
+
+cp = classes;
+for(cf = cclass_factories; cf-name != NULL; cf++)
+{
+cp-name = strdup(cf-name);
+if ( cf-chars )
+cp-chars = strdup(cf-chars);
+else
+{
+int x = 0, y = 0;
+cp-chars = malloc(sizeof(char) * 256);
+if (cp-chars == NULL)
+elog(ERROR,cclass_init: out of memory);
+for (x = 0; x 256; x++)
+{
+if((cf-func)(x))
+*(cp-chars + y++) = x;
+}
+*(cp-chars + y) = '\0';
+}
+cp-multis = ;
+cp++;
+}
+cp-name = cp-chars = NULL;
+cp-multis = ;
+
+return classes;
+}
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] regexp character class locale awareness patch
According to POSIX -regex (7)-, standard character class are: alnum digit punct alpha graph space blank lower upper cntrl print xdigi Many of that classes are different in different locales, and currently all work as if the localization were C. Many of those tests have multibyte issues, however with the patch postgres will work for one-byte encondings, which is better than nothing. If someone (Tatsuo?) gives some advice I will work in the multibyte version. Peter Eisentraut [EMAIL PROTECTED] writes: Basically, you manually preprocess the patch to include the USE_LOCALE branch and remove the not USE_LOCALE branch. Yeah, that should work. You may also remove include/regex/cclass.h since it will not be used any more. However, if the no-locale branches have significant performance benefits then it might be worth pondering setting up some optimizations. This is not the case. Regards, Manuel. ---(end of broadcast)--- TIP 3: 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] regexp character class locale awareness patch
Tatsuo Ishii [EMAIL PROTECTED] writes: I don't think character classes are applicable for most mutibyte encodings. Maybe only the exeception is Unicode? Maybe, and is the only one I need ;-) Peter Eisentraut [EMAIL PROTECTED] writes: Basically, you manually preprocess the patch to include the USE_LOCALE branch and remove the not USE_LOCALE branch. Yeah, that should work. You may also remove include/regex/cclass.h since it will not be used any more. But I don't like cclass_init() routine runs every time when reg_comp called. Actually it is called once per backend and only if it uses the regular expression engine. In my understanding the result of cclass_init() is always same. Yes, if localization does not change. Karel once talked about the possibility of being able to have different locales in the same DB. What about running cclass_init() in postmaster, not postgres? Or even better in initdb time? It might be, but ... I think that it would be nice if we leave the door open to the possibility of having mixed locale configurations, across data bases or even across columns of the same table. Regards, Manuel. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
