okbob/plpgsql_check

Segmentation fault on EXECUTE empty string

M-Butter opened this issue · 3 comments

M-Butter commented

When I have a procedure that contains an EXECUTE statement with an empty string ('') as argument, or just comment ('--') as argument, and I run plpgsql_check on that function, then a segmentation fault is the result:

[mb@mb-laptop ~]$ psql -d postgres
psql (16.1)
Type "help" for help.

postgres=# create database test;
CREATE DATABASE

postgres=# \c test
You are now connected to database "test" as user "mb".

test=# create schema test;
CREATE SCHEMA

test=# create extension plpgsql_check;
CREATE EXTENSION

test=# select extversion from pg_extension where extname = 'plpgsql_check';
extversion
------------
2.6
(1 row)

test=# CREATE OR REPLACE PROCEDURE test.test_execute_empty()
LANGUAGE 'plpgsql'
AS $BODY$
begin
execute '';
end;
$BODY$;
CREATE PROCEDURE

test=# call test.test_execute_empty();
CALL

test=# select * from plpgsql_check_function('test.test_execute_empty', 0, 'text', false, false, false, false);
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
The connection to the server was lost. Attempting reset: Failed.

From the server log:

2023-11-22 08:40:08.297 CET [141327] LOG: server process (PID 250331) was terminated by signal 11: Segmentation fault
2023-11-22 08:40:08.297 CET [141327] DETAIL: Failed process was running: select * from plpgsql_check_function('test.test_execute_empty', 0, 'text', false, false, false, false);
2023-11-22 08:40:08.297 CET [141327] LOG: terminating any other active server processes
2023-11-22 08:40:08.299 CET [250699] FATAL: the database system is in recovery mode
2023-11-22 08:40:08.300 CET [141327] LOG: all server processes terminated; reinitializing
2023-11-22 08:40:08.336 CET [250703] LOG: database system was interrupted; last known up at 2023-11-22 08:36:22 CET
2023-11-22 08:40:09.461 CET [250703] LOG: database system was not properly shut down; automatic recovery in progress
2023-11-22 08:40:09.465 CET [250703] LOG: redo starts at 5/646B3FC8
2023-11-22 08:40:09.466 CET [250703] WARNING: could not open directory "base/996474": No such file or directory
2023-11-22 08:40:09.466 CET [250703] CONTEXT: WAL redo at 5/646B40C8 for Database/DROP: dir 1663/996474
2023-11-22 08:40:09.466 CET [250703] WARNING: some useless files may be left behind in old database directory "base/996474"
2023-11-22 08:40:09.466 CET [250703] CONTEXT: WAL redo at 5/646B40C8 for Database/DROP: dir 1663/996474
2023-11-22 08:40:09.478 CET [250703] LOG: invalid record length at 5/64B24988: expected at least 24, got 0
2023-11-22 08:40:09.478 CET [250703] LOG: redo done at 5/64B24950 system usage: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.01 s
2023-11-22 08:40:09.486 CET [250704] LOG: checkpoint starting: end-of-recovery immediate wait
2023-11-22 08:40:09.530 CET [250704] LOG: checkpoint complete: wrote 968 buffers (5.9%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.022 s, sync=0.018 s, total=0.046 s; sync files=305, longest=0.004 s, average=0.001 s; distance=4546 kB, estimate=4546 kB; lsn=5/64B24988, redo lsn=5/64B24988
2023-11-22 08:40:09.554 CET [141327] LOG: database system is ready to accept connections
2023-11-22 08:40:09.558 CET [250711] LOG: pg_cron scheduler started

okbob commented

should be fixed by 463ac3a commit.

You are first man who used empty string there in my 20 years work with plpgsql :-).

M-Butter commented

Hello Pavel,

The problem originates from a migrated Oracle procedure that contained an execute immediate 'create table ...' statement. Our migration software decided that the create table statement needed extra attention, so commented it out inside the create table string. The empty string was just a simplified version of that, which caused the same problem.

Thanks for fixing,
Martin.

okbob commented