postgresql错误:临时表

时间:2016-10-25 18:55:08

标签: postgresql pgadmin postgresql-9.6

我发现这个相当简单的postgresql 9.6函数

CREATE OR REPLACE FUNCTION public.trying_to_index_me()
RETURNS VOID  AS
$BODY$
    BEGIN
    CREATE TABLE public.table_to_index ( 
        id INTEGER NOT NULL,    
        this_id UUID NOT NULL,
        that_id smallint NOT NULL,
        CONSTRAINT idx_table_to_index_unique
            UNIQUE (id,this_id,that_id)     
    ); 
    CREATE INDEX idx_table_to_index_thisthat ON public.table_to_index(this_id,that_id);  
    DROP TABLE public.table_to_index;
END;
$BODY$ LANGUAGE plpgsql;

--SELECT public.trying_to_index_me();

导致schema "" does not exist error。确切的错误是:

ERROR:  schema "" does not exist
SQL state: 3F000
Context: SQL statement "CREATE INDEX idx_table_to_index_thisthat 
ON public.table_to_index(this_id,that_id)" 
PL/pgSQL function trying_to_index_me() line 10 at SQL statement

并在第二次和后续执行时可靠地发生。剪切/粘贴上面的SQL块会为我重现错误....非常感兴趣,如果不适合你。我有以下线索:

  • 错误消息中检测到的架构会有所不同。大多数情况下它被报告为“”,但其他人喜欢“0MA {Text of Text}”或者来自事务中先前语句的一些sql语句/注释片段。听起来与内存指针有关。
  • 一旦进入,它就会一直出错。
  • 我发现如果我创建或替换该函数,我将获得一次执行,然后再次出现错误状态。
  • 我发现如果我打开一个新的pgadminIII窗口(没有删除或重新创建),我将获得相同的一次执行,然后错误的状态将再次发生...无论它是否在另一个窗口中出错。声音连接相关。
  • 我发现评论idx_temp_data_to_index_thisthatidx_temp_data_to_index_unique的创建可以解决问题。
  • 发生在x86_64-pc-linux-gnu上的PostgreSQL 9.5.3,由gcc(GCC)4.4.7 20120313(Red Hat 4.4.7-16)编译,64位“和9.6实现中。
  • 如果从另一个函数执行上述函数,则仅在替换子函数时,上面的CREATE OR REPLACE FUNCTION 1次解析对父函数不起作用。如果这发生在单独的pgadmin窗口中并不重要。像客户端或交易一样。

真的很感激你的想法。

2 个答案:

答案 0 :(得分:1)

我认为在that_id smallint NOT NULL

之后缺少逗号
CREATE OR REPLACE FUNCTION trying_to_index_me()
RETURNS VOID  AS
$BODY$
    BEGIN
    CREATE Temporary TABLE temp_data_to_index ( 
        id INTEGER NOT NULL,    
        this_id UUID NOT NULL,
        that_id smallint NOT NULL,
        CONSTRAINT idx_temp_data_to_index_unique
            UNIQUE (id,this_id,that_id)     
    ); 
    CREATE INDEX idx_temp_data_to_index_thisthat ON temp_data_to_index(this_id,that_id);  
    DROP TABLE temp_data_to_index;
END;
$BODY$ LANGUAGE plpgsql VOLATILE COST 100;

答案 1 :(得分:1)

这似乎是由citus数据扩展引起的。该错误是由超出默认堆栈2M时发生的内存损坏引起的。它不会显示在日志中,也不会使其超出本应抛出的“超出堆栈深度限制”异常。

这都是投机指责。

卸载citus扩展程序为我解决了这个问题。