[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 2b
[BUGS] 7.03 JDBC drivers & large objects
Hi, this just cropped up on the Orion app-server list - someone there was having trouble storing large objects via JDBC in Postgres using the standard PreparedStatement.setBinaryStream() method. I tried the same test outside of Orion using a simple command-line app and hit the same problem. Poking around in the source code for the JDBC drivers it looks like this hasn't been implemented yet, but also that there's possibly a lot of stuff missing in the large objects API too. Any fixes available? I assume it worked in 6.5, so will a downgrade help?? (I'm pretty sure there are people out there using Orion with Postgres so there must be some workaround...) cheers Jules ---(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
[BUGS] pg_restore silently chokes on object comments/descriptions ending in a backslash
I observe the following issue on PostgreSQL 9.0.4 on at least the
following platforms:
* FreeBSD 6.3 (amd64)
`uname -a`:
FreeBSD 6.3-STABLE FreeBSD 6.3-STABLE #1: Fri May 30 18:11:47
PDT 2008
root@:/data/obj/data/home//symbols/builddir_amd64/usr/src/sys/MESSAGING_GATEWAY.amd64_INSTALL
amd64
* Mac OS X 10.6.8 (i386)
`uname -a`:
Darwin joule 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:33:36 PDT
2011; root:xnu-1504.15.3~1/RELEASE_I386 i386 i386
* semi-current Debian testing (amd64)
`uname -a`:
Linux gray 2.6.30-2-amd64 #1 SMP Mon Dec 7 05:21:45 UTC 2009 x86_64
GNU/Linux
If the comment/description of a database object (table, function, etc.)
ends in a backslash (which generally works fine otherwise), then
pg_restore is unable to completely restore a custom-format dump of the
schema. pg_restore does not complain, but silently(!) stops issuing DDL
statements to the server starting with the first "COMMENT ON …" statement
that would have set an object comment/description ending in a backslash.
Reproduce as follows:
$ createdb test0
$ createdb test1
$ psql -c "CREATE TABLE bar (); COMMENT ON TABLE bar IS 'bar\\';" test0
COMMENT
$ psql -c "CREATE TABLE foo (); COMMENT ON TABLE foo IS 'foo';" test0
COMMENT
$ pg_dump --format custom --file test0.pg_dump --schema-only test0
$ pg_restore -d test1 test0.pg_dump
$ psql -c '\dt+' test0
List of relations
Schema | Name | Type | Owner | Size | Description
+--+---+----+-+-
public | bar | table | julian | 0 bytes | bar\
public | foo | table | julian | 0 bytes | foo
(2 rows)
$ psql -c '\dt+' test1
List of relations
Schema | Name | Type | Owner | Size | Description
+--+---++-+-
public | bar | table | julian | 0 bytes |
(1 row)
This also happens with PostgreSQL 8.4.
To demonstrate that this is not an academic issue, these are a few
functions I have defined, and their comments:
List of functions
-[ RECORD 1
]---+
Schema | public
Name| escape_are
... : ...
Description | escape advanced regexp (ARE) special characters:
.*+?|[](){}^$\
-[ RECORD 2
]---+
Schema | public
Name| escape_control
... : ...
Description | escape control characters: \a\b\t\n\v\f\r\e\\
-[ RECORD 3
]---+
Schema | public
Name| escape_like
... : ...
Description | escape LIKE pattern special characters: %_\
I have worked around the issue by appending a space character to each of
those function descriptions. What makes the problem really bad is that it
silently renders your custom-format database dumps (which pg_dump creates
just fine) useless, which you notice only after you do a restore (without
an error being thrown) and your restored database being incomplete.
-Julian
signature.asc
Description: This is a digitally signed message part.
Re: [BUGS] pg_restore silently chokes on object comments/descriptions ending in a backslash
I'm subscribed to the pgsql-bugs list, so no need to CC me. :-) Tom Lane wrote: > Reproduced here against HEAD. The problem seems to be that > pg_backup_db.c's _sendSQLLine() contains a mini SQL lexer that is not > cognizant of standard_conforming_strings. Oh, right, I forgot to mention I have standard_conforming_strings enabled. However, I understand that is to become the new default anyway. > Not sure about a simple fix, > and I rather wonder if we shouldn't try to remove that code entirely > instead of "fix" it. What would "removing that code entirely" mean? > As a temporary workaround, the SQL text file that pg_restore produces > by default seems to be valid, so you could pipe that into psql. Hmm, right. So at least my existing dumps aren't useless. Thanks. -Julian signature.asc Description: This is a digitally signed message part.
Re: [BUGS] pg_restore silently chokes on object comments/descriptions ending in a backslash
Tom Lane wrote: > Julian Mehnle writes: > > I'm subscribed to the pgsql-bugs list, so no need to CC me. :-) > > cc to people in the thread is the established practice on these lists. > It provides a bit more robustness when the lists are busy or slow. Got it. I'll try to remember that and CC others when posting, and will also not take offense when receiving extra CCs. > > What would "removing that code entirely" mean? > > I was wondering why it's necessary to parse the entry in the dump file > at all, rather than just spit it out to PQexec as-is. There's probably > a reason, but maybe we can find another way to solve whatever the > real problem is. I see. Given that I'm only a Pg user, not a Pg developer, I have no opinion on this. Thanks for the explanation, though! -Julian signature.asc Description: This is a digitally signed message part.
Re: [BUGS] pg_restore silently chokes on object comments/descriptions ending in a backslash
Alvaro Herrera wrote: > Note that CCing others is customary but obviously not mandatory. For the record, CCing posters who haven't explicitly requested it is frowned upon on the Debian mailing lists , but apparently those have a lower latency than the Pg ones. :-) I'll shut up now since this is drifting off topic. -Julian signature.asc Description: This is a digitally signed message part.
