Re: [BUGS] Postgresql 7.3.3 crashing on query
Am Montag, 28. Juli 2003 15:53 schrieb Tom Lane: > Philipp Reisner <[EMAIL PROTECTED]> writes: > > If I execute this query several times (I receive the correct result set), > > and then do an explain of the same query, the backend terminates with > > sig 11 !!! > > Can you get us a debugger stack trace from the crash? > Ok, I attached GDB to the backend. Attaching to program: /usr/lib/postgresql/bin/postgres, process 25380 Reading symbols from /lib/libpam.so.0...(no debugging symbols found)...done. Loaded symbols for /lib/libpam.so.0 Reading symbols from /usr/lib/libssl.so.0.9.6...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libssl.so.0.9.6 Reading symbols from /usr/lib/libcrypto.so.0.9.6...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libcrypto.so.0.9.6 Reading symbols from /usr/lib/libkrb5.so.17...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libkrb5.so.17 Reading symbols from /usr/lib/libz.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libz.so.1 Reading symbols from /lib/libreadline.so.4...(no debugging symbols found)...done. Loaded symbols for /lib/libreadline.so.4 Reading symbols from /lib/libcrypt.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /lib/libresolv.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /lib/libnsl.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /usr/lib/libcom_err.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libcom_err.so.1 Reading symbols from /usr/lib/libasn1.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libasn1.so.5 Reading symbols from /usr/lib/libroken.so.9...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libroken.so.9 Reading symbols from /lib/libncurses.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libncurses.so.5 Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /usr/lib/libdb3.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libdb3.so.3 Reading symbols from /lib/libnss_compat.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libnss_compat.so.2 0x402be812 in recv () from /lib/libc.so.6 (gdb) c Continuing. Program received signal SIGSEGV, Segmentation fault. 0x0812f9bc in DecodeDateTime () (gdb) where #0 0x0812f9bc in DecodeDateTime () Cannot access memory at address 0xbf003030 Looks a lot like a corrupted stack :( > Also you should specify the platform you're using in reports of this sort. > Its a PIII 733MHz 256MB RAM, running Debian Linux 3.0 (Woody) an a 2.4.18 kernel. BTW, it crashes are getting rarer on the system... -Philipp -- : Dipl-Ing Philipp Reisner Tel +43-1-8178292-50 : : LINBIT Information Technologies GmbH Fax +43-1-8178292-82 : : Schönbrunnerstr 244, 1120 Vienna, Austriahttp://www.linbit.com : ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] what about function parameter count limit?
On Wed, 30 Jul 2003, sad wrote: > good day > we are suffering of the limit of parameters count in functions > 16 parameters is not enough What version are you using? I believe 7.3 raised the default to 32 and in all versions I've used there's a compile time define that can be raised (look for FUNC_MAX_ARGS I think). ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] Postgresql 7.3.3 crashing on query
Philipp Reisner <[EMAIL PROTECTED]> writes: > Program received signal SIGSEGV, Segmentation fault. > 0x0812f9bc in DecodeDateTime () > (gdb) where > #0 0x0812f9bc in DecodeDateTime () > Cannot access memory at address 0xbf003030 That's a fairly large routine :-(. Could I trouble you to rebuild with debugging symbols (configure --enable-debug) so we can get a more exact fix on the problem location? While you're at it, please add --enable-cassert too, just in case that produces any useful info. Alternatively: maybe you can now create a simple test case. This is enough information to let us guess that the crash occurs while trying to read an unusual date or timestamp input value. Do you know what's getting fed to the database? If you can exhibit a crash with a test case like "SELECT 'something odd'::timestamp", we could take it from there. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
[BUGS]
Could you please confirm whether this behavior of PostgreSQL is a bug or a feature? Issue occurs wirh PostgreSQL 7.3.3 compiled with GCC 3.2.3 on aCeleron Coppermine 1100 MHz powerd by Linux 2.4.21 I have two functions, one is called by a trigger, the other by user. Both are written in PL/pgSQL. The trigger fires after an INSERT on a table. The triggerd function requires the max value of the SEQUENCE of that table. (SELECT INTO max last_value FROM table_ID_seq;) This works quite excellent as long as I execute common INSERTS. Now, the user-called function executes several INSERTS at once, and the trigger also is fired several times, but AFTER the complete function is done, and not after each specific INSERT, as I expected. This confuses me since my trigger was created with FOR EACH ROW. This behavior leads to the following problem: After the function made e.g. 5 INSERTS, the trigger called function is triggered 5 times at once. Each instance of the function now gets n+5 n+5 n+5 n+5 n+5 instead of n+1 n+2 n+3 n+4 n+5 as supposed. Is the described behavior a bug or a feature? Any recommendations? If its a feature, can u give me a short explaination why its done that way? Regards, Joacher -- COMPUTERBILD 15/03: Premium-e-mail-Dienste im Test -- 1. GMX TopMail - Platz 1 und Testsieger! 2. GMX ProMail - Platz 2 und Preis-Qualitätssieger! 3. Arcor - 4. web.de - 5. T-Online - 6. freenet.de - 7. daybyday - 8. e-Post ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [BUGS] Small problem in contrib/dbase/dbf2pg.c
Patch applied. Thanks.
---
Thomas Behr wrote:
> Hej!
>
> select version();
>version
> --
> PostgreSQL 7.3.3 on sparc-sun-solaris2.7, compiled by cc -Xa
>
> On 23 Jul 2003, Bruce Momjian wrote:
> > Thomas, would you send me a context diff (diff -c) of the change and I
> > will get into 7.4. Thanks.
>
> I hope, it is OK.
>
> Thomas
>
>
> 8<-8<--8<--
>
> *** dbf2pg.c Thu Oct 31 20:11:48 2002
> --- dbf2pg.c.TB Thu Jul 24 13:09:48 2003
> ***
> *** 194,200
> printf("dbf2pg\n"
> "usage: dbf2pg [-u | -l] [-h hostname] [-W] [-U username]\n"
> " [-B transaction_size] [-F charset_from [-T
> charset_to]]\n"
> !" [-s oldname=newname[,oldname=newname[...]]] [-d
> dbase]\n"
> " [-t table] [-c | -D] [-f] [-v[v]] dbf-file\n");
> }
>
> --- 194,200
> printf("dbf2pg\n"
> "usage: dbf2pg [-u | -l] [-h hostname] [-W] [-U username]\n"
> " [-B transaction_size] [-F charset_from [-T
> charset_to]]\n"
> !" [-s oldname=[newname][,oldname=[newname][...]]] [-d
> dbase]\n"
> " [-t table] [-c | -D] [-f] [-v[v]] dbf-file\n");
> }
>
> ***
> *** 359,364
> --- 359,365
> field *fields;
> int i,
> h,
> + j,
> result;
> char *query,
> *foo;
> ***
> *** 442,453
> if (result == DBF_VALID)
> {
> query[0] = '\0';
> for (h = 0; h < dbh->db_nfields; h++)
> {
> ! if (!strlen(fields[h].db_name))
> continue;
>
> ! if (h != 0) /* not for the first field! */
> strcat(query, "\t");/* COPY
> statement field
>
> * separator */
>
> --- 443,461
> if (result == DBF_VALID)
> {
> query[0] = '\0';
> + j = 0; /* counter for fields in the output */
> for (h = 0; h < dbh->db_nfields; h++)
> {
> ! if (!strlen(fields[h].db_name)) /* When the new
> fieldname is empty, the field is skipped */
> ! {
> continue;
> + }
> + else
> + {
> + j++;
> + }
>
> ! if (j > 1) /* not for the first field! */
> strcat(query, "\t");/* COPY
> statement field
>
> * separator */
>
>
> 8<-8<--8<--
>
> *** README.dbf2pg Fri Dec 21 06:29:46 2001
> --- README.dbf2pg.TB Thu Jul 24 13:28:35 2003
> ***
> *** 12,18
> "dbf2pg [options] dbf-file"
> Options:
> [-v[v]] [-f] [-u | -l] [-c | -D] [-d database] [-t table]
> ![-h host] [-s oldname=newname[,oldname=newname]] [-s
> start] [-e end] [-W] [-U username] [-B transaction_size]
> [-F charset_from [-T charset_to]]
>
> --- 12,18
> "dbf2pg [options] dbf-file"
> Options:
> [-v[v]] [-f] [-u | -l] [-c | -D] [-d database] [-t table]
> ![-h host] [-s oldname=[newname][,oldname=[newname]]] [-b
> start] [-e end] [-W] [-U username] [-B transaction_size]
> [-F charset_from [-T charset_to]]
>
> ***
> *** 70,84
> dbf2sql(1L) dbf2sql(1L)
>
>
> !-s oldname=newname[,oldname=newname]
> Change the name of a field from oldname to newname.
> This is mainly used to avoid using reserved SQL-
> ! keywords. Example:
> ! -s SELECT=SEL,COMMIT=doit
> This is done before the -f operator has taken
> effect!
>
> !-s start
> Specify the first record-number in the xBase-file
> we will insert.
>
> --- 70,88
> dbf2sql(1L) dbf2sql(1L)
>
>
> !-s oldname=[newnam
Re: [BUGS]
[EMAIL PROTECTED] writes: > Now, the user-called function executes several INSERTS at once, and > the trigger also is fired several times, but AFTER the complete > function is done, and not after each specific INSERT, as I expected. AFTER triggers fire at the end of the SQL statement. Presently this is taken to mean "at the end of the complete interactive statement", ie, just before we go back to waiting for client input. There has been some discussion of changing it so that when an INSERT (resp. UPDATE or DELETE) is done within a function, any triggers fired are executed at completion of that statement before proceeding with the function. We've not made the change yet though. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
