Thread: 8.2 bug: Mixing spi_prepare and spi_exec_query causes postgresql to terminate itself on bad argument types
8.2 bug: Mixing spi_prepare and spi_exec_query causes postgresql to terminate itself on bad argument types
From
Michael Andreen
Date:
Was playing around with the new release and changing some pl/perl functions to use the new spi_prepare and friends when I noticed postgresql terminating strangely, with no useful warnings at all, the log contained the following: Dec 7 16:58:28 [postgres] [7-1] LOG: database system is ready Dec 7 16:58:46 [postgres] [2-1] LOG: could not receive data from client: Connection reset by peer Dec 7 16:58:56 [postgres] [2-1] LOG: server process (PID 26649) was terminated by signal 11 Dec 7 16:58:56 [postgres] [3-1] LOG: terminating any other active server processes Dec 7 16:58:56 [postgres] [4-1] LOG: all server processes terminated; reinitializing Dec 7 16:58:56 [postgres] [5-1] LOG: database system was interrupted at 2006-12-07 16:58:28 CET After some playing around I tracked it down to a spi_prepare line where I had specified 'integer' as type instead of 'int4'. Tried to create a simple function to reproduce the bug: CREATE OR REPLACE FUNCTION nocrash() RETURNS int4 AS $BODY$$query = spi_prepare('SELECT 1 WHERE 1 = $1','integer'); return 1;$BODY$ LANGUAGE 'plperl' VOLATILE; But this gave a nice error message: ERROR: error from Perl function: type "integer" does not exist at line 1. After some more work I realized that I still had a few spi_exec_query calls in the script and adding one to my test case caused postgresql to terminate just like before. CREATE OR REPLACE FUNCTION crash() RETURNS int4 AS $BODY$$rv = spi_exec_query("SELECT 1"); $query = spi_prepare('SELECT 1 WHERE 1 = $1','integer'); return 1;$BODY$ LANGUAGE 'plperl' VOLATILE;