The following crashes posgresql 9.4.8 when executed. I'm not sure whose fault it is, but I thot I'd start with you.
CREATE OR REPLACE FUNCTION y() RETURNS text
SET search_path TO public
AS $$
SELECT 'test_search_documents'::text;
$$ LANGUAGE SQL;
CREATE OR REPLACE FUNCTION x() RETURNS sphinx_search_result
AS $$
SELECT sphinx_select(y(),'stuff',null,null,0,0,null);
$$ LANGUAGE SQL;
SELECT x();
Generates the following in the log:
LOG: server process (PID 14672) was terminated by signal 11: Segmentation fault
DETAIL: Failed process was running: select x();
LOG: terminating any other active server processes
WARNING: terminating connection because of crash of another server process
DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
HINT: In a moment you should be able to reconnect to the database and repeat your command.
FATAL: the database system is in recovery mode
Removing the SET search_path TO public "fixes" the problem, but I feel there is a subtler issue at play.
The following crashes posgresql 9.4.8 when executed. I'm not sure whose fault it is, but I thot I'd start with you.
CREATE OR REPLACE FUNCTION y() RETURNS text
SET search_path TO public
AS $$
SELECT 'test_search_documents'::text;
$$ LANGUAGE SQL;
CREATE OR REPLACE FUNCTION x() RETURNS sphinx_search_result
AS $$
SELECT sphinx_select(y(),'stuff',null,null,0,0,null);
$$ LANGUAGE SQL;
SELECT x();
Generates the following in the log:
LOG: server process (PID 14672) was terminated by signal 11: Segmentation fault
DETAIL: Failed process was running: select x();
LOG: terminating any other active server processes
WARNING: terminating connection because of crash of another server process
DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
HINT: In a moment you should be able to reconnect to the database and repeat your command.
FATAL: the database system is in recovery mode
Removing the SET search_path TO public "fixes" the problem, but I feel there is a subtler issue at play.