[BUGS] BUG #3523: plpython crash
The following bug has been logged online: Bug reference: 3523 Logged by: Julian Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2.4 Operating system: Linux Description:plpython crash Details: -- PostgreSQL 8.2.4 on x86_64-pc-linux-gnu, compiled by GCC x86_64-pc-linux-gnu-gcc (GCC) 4.1.2 (Gentoo 4.1.2) --see if this crashes for you. BEGIN; CREATE FUNCTION pyfunction(tuple record) RETURNS "void" LANGUAGE "plpythonu" AS $$ $$ ; CREATE FUNCTION mytrigger () RETURNS "trigger" LANGUAGE "plpgsql" AS $$ BEGIN PERFORM pyfunction(NEW); END; $$ ; CREATE TABLE mytable (mycol text) ; CREATE TRIGGER mytrigger AFTER INSERT ON mytable FOR EACH ROW EXECUTE PROCEDURE mytrigger(); INSERT INTO mytable SELECT 'test'; ROLLBACK; -BACKTRACE LOG: database system was interrupted at 2007-08-09 03:17:53 EST LOG: checkpoint record is at 0/5471B260 LOG: redo record is at 0/5471B260; undo record is at 0/0; shutdown TRUE LOG: next transaction ID: 0/196948; next OID: 608885 LOG: next MultiXactId: 1; next MultiXactOffset: 0 LOG: database system was not properly shut down; automatic recovery in progress LOG: redo starts at 0/5471B2B0 LOG: unexpected pageaddr 0/51862000 in log file 0, segment 84, offset 8790016 LOG: redo done at 0/54861E68 LOG: database system is ready *** glibc detected *** postgres: test test2 [local] INSERT: double free or corruption (out): 0x2b7d14e40a30 *** === Backtrace: = /lib/libc.so.6[0x2b7d14c74b1d] /lib/libc.so.6(__libc_free+0x76)[0x2b7d14c76146] /usr/lib64/postgresql/plpython.so[0x2b7d16f32870] /usr/lib64/postgresql/plpython.so[0x2b7d16f32a77] /usr/lib64/postgresql/plpython.so(plpython_call_handler+0xbd)[0x2b7d16f3416d ] postgres: test test2 [local] INSERT(ExecMakeFunctionResult+0xfd)[0x4ff0dd] postgres: test test2 [local] INSERT(ExecProject+0x1c1)[0x4fd971] postgres: test test2 [local] INSERT(ExecResult+0x63)[0x50d473] postgres: test test2 [local] INSERT(ExecProcNode+0xc6)[0x4fd176] postgres: test test2 [local] INSERT(ExecutorRun+0x10a)[0x4fc47a] postgres: test test2 [local] INSERT[0x5130cb] postgres: test test2 [local] INSERT(SPI_execute_plan+0xad)[0x51332d] /usr/lib64/postgresql/plpgsql.so[0x2b7d16e1c310] /usr/lib64/postgresql/plpgsql.so[0x2b7d16e1ee43] /usr/lib64/postgresql/plpgsql.so[0x2b7d16e1e48a] /usr/lib64/postgresql/plpgsql.so(plpgsql_exec_trigger+0x358)[0x2b7d16e20448] /usr/lib64/postgresql/plpgsql.so(plpgsql_call_handler+0x152)[0x2b7d16e17c92] postgres: test test2 [local] INSERT[0x4e7b28] postgres: test test2 [local] INSERT[0x4e91c2] postgres: test test2 [local] INSERT(AfterTriggerEndQuery+0x55)[0x4e9545] postgres: test test2 [local] INSERT[0x582d29] postgres: test test2 [local] INSERT[0x582ea8] postgres: test test2 [local] INSERT(PortalRun+0x364)[0x583714] postgres: test test2 [local] INSERT[0x57f745] postgres: test test2 [local] INSERT(PostgresMain+0x1110)[0x580b70] postgres: test test2 [local] INSERT[0x55a3e7] postgres: test test2 [local] INSERT(PostmasterMain+0x6c1)[0x55afa1] postgres: test test2 [local] INSERT(main+0x183)[0x51c993] /lib/libc.so.6(__libc_start_main+0xf4)[0x2b7d14c27374] postgres: test test2 [local] INSERT[0x43e6c9] === Memory map: 0040-00701000 r-xp 08:19 10261 /usr/bin/postgres 0080-0080c000 rw-p 0030 08:19 10261 /usr/bin/postgres 0080c000-009fb000 rw-p 0080c000 00:00 0 [heap] 2b7d1411a000-2b7d14135000 r-xp 08:19 948791 /lib64/ld-2.5.so 2b7d14135000-2b7d14157000 rw-p 2b7d14135000 00:00 0 2b7d14163000-2b7d141e7000 rw-p 2b7d14163000 00:00 0 2b7d14235000-2b7d14236000 r--p 0001b000 08:19 948791 /lib64/ld-2.5.so 2b7d14236000-2b7d14237000 rw-p 0001c000 08:19 948791 /lib64/ld-2.5.so 2b7d14237000-2b7d1423f000 r-xp 08:19 571744 /lib64/libpam.so.0.78 2b7d1423f000-2b7d1433e000 ---p 8000 08:19 571744 /lib64/libpam.so.0.78 2b7d1433e000-2b7d1433f000 rw-p 7000 08:19 571744 /lib64/libpam.so.0.78 2b7d1433f000-2b7d1437f000 r-xp 08:19 238686 /usr/lib64/libssl.so.0.9.8 2b7d1437f000-2b7d1447f000 ---p 0004 08:19 238686 /usr/lib64/libssl.so.0.9.8 2b7d1447f000-2b7d14485000 rw-p 0004 08:19 238686 /usr/lib64/libssl.so.0.9.8 2b7d14485000-2b7d145d r-xp 08:19 249759 /usr/lib64/libcrypto.so.0.9.8 2b7d145d-2b7d146cf000 ---p 0014b000 08:19 249759 /usr/lib64/libcrypto.so.0.9.8 2b7d146cf000-2b7d146f2000 rw-p 0014a000 08:19 249759 /usr/lib64/libcrypto.so.0.9.8 2b7d146f2000-2b7d146f7000 rw-p 2b7d146f2000 00:00 0 2b7d146f7000-2b7d14778000 r-xp 08:19 398203 /usr/lib64/libkrb5.so.3.2 2b7d14778000-2b7d14878000 ---p 00081000 08:19 398203
[BUGS] BUG #3525: Lithuanian characters doesn't work in queries with regular expressions
The following bug has been logged online: Bug reference: 3525 Logged by: Rolandas Rudomanskis Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2.3 Operating system: Debian Etch Description:Lithuanian characters doesn't work in queries with regular expressions Details: The database is set to unicode. Debian locale is utf-8. All lithuanian characters characters, except Ä, ų, namely, Ä , Ä, Ä, į, Å¡, Å«, ž in non-case sensitive queries specifying word beginning, are ignored. SQL example: select * from table1 where title ~* '\\m" + mytext + "';" ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] BUG #3504: Some listening sessions never return from writing, problems ensue
On 8/6/07, Tom Lane <[EMAIL PROTECTED]> wrote: > "Peter Koczan" <[EMAIL PROTECTED]> writes: > > Here's my theory (and feel free to tell me that I'm full of it)...somehow, a > > lot of notifies happened at once, or in a very short period of time, to the > > point where the app was still processing notifies when the timer clicked off > > another second. The connection (or app, or perl module) never marked those > > notifies as being processed, or never updated its timestamp of when it > > finished, so when the next notify came around, it tried to reprocess the old > > data (or data since the last time it finished), and yet again couldn't > > finish. Lather, rinse, repeat. In sum, it might be that trying to call > > pg_notifies while processing notifies tickles a race condition and tricks > > the connection into thinking its in a bad state. > > Hmm. Is the app trying to do this processing inside an interrupt > service routine (a/k/a signal handler)? If so, and if the ISR can > interrupt itself, then you've got a problem because you'll be doing > reentrant calls of libpq, which it doesn't support. You can only make > that work if the handler blocks further occurrences of its signal until > it finishes. > I'm not entirely sure if this answers your question, but here's what I found out from the primary maintainer of the app. Note that update_reqs is the function calling pg_notifies. If there's more information I can provide or another test we can run, please let me know. --- BEGIN MESSAGE --- I just checked and the timer won't interrupt update_reqs, so we'll have to look for another solution. Anyway, update_reqs doesn't do anything with the database except for checking for a notify, so I don't see where it can be interrupted to cause DB problems. --- END MESSAGE --- I also found out that one notify gets sent per action (not per batch of actions), so if n requests get resolved at once, n notifies are sent, not 1. In theory this could mitigate this problem, but I don't know how easy it is at this point. Still, it doesn't explain how or why the client's recv-q isn't getting cleared. Hope this helps. Peter ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] BUG #3525: Lithuanian characters doesn't work in queries with regular expressions
"Rolandas Rudomanskis" <[EMAIL PROTECTED]> writes: > Description:Lithuanian characters doesn't work in queries with > regular expressions > The database is set to unicode. Debian locale is utf-8. Yeah, the regex code doesn't handle localization issues (such as case-insensitive matching) correctly for multibyte characters. Can you use a single-byte encoding? Alternatively, I believe case-insensitive LIKE matching works for this. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #3523: plpython crash
"Julian" <[EMAIL PROTECTED]> writes: > --see if this crashes for you. Yup. I think this'll fix it: Index: plpython.c === RCS file: /cvsroot/pgsql/src/pl/plpython/plpython.c,v retrieving revision 1.90 diff -c -r1.90 plpython.c *** plpython.c 21 Nov 2006 21:51:05 - 1.90 --- plpython.c 10 Aug 2007 02:01:04 - *** *** 1237,1242 --- 1237,1243 "proargnames must have the same number of elements " "as the function has arguments"); proc->argnames = (char **) PLy_malloc(sizeof(char *) * proc->nargs); + memset(proc->argnames, 0, sizeof(char *) * proc->nargs); } } for (i = 0; i < fcinfo->nargs; i++) regards, tom lane ---(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
