PostgreSQL 9.4 突然无效的内存分配请求大小

Question

我正在构建一个网站，该网站将用于处理商店中的 excel 文件并对其进行操作(合并、查看等)。我正在为数据库使用 PostgreSQL 9.4，在具有 4GB RAM 的 Centos 6.6 VM 上运行。它有3个数据库如下:

• postgres 数据库
• db_raw，用作数据的占位符。从网站上传的excel会被解析，数据会存储在这里。该数据库由几个用于保存处理 excel 所需数据的表和一个用于存储当前超过 140 列和近 100 万行的 excel 数据的巨大表组成
• db_processed，这是网站的主要数据库。它有几个用于网站运行的小表(用户表、访问列表、日志记录等)，还有 8 个表用于存储来自 db_raw 的处理后的 excel 数据。 8 个表格中的每一个都有大约 40 列和大约 100 万行。

直到今天早上，数据库都运行良好。我尝试通过 pgAdmin 和 PuTTY 连接到 db_processed，PostgreSQL 给了我这条消息

FATAL:  invalid memory alloc request size 144115188075856068

db_raw 工作正常，据我所知自 3 天前以来没有任何变化。我应该怎么做才能再次连接到数据库？

更新:我做了@CraigRinger 所说的并重新启动了服务。我设法连接到数据库，但是所有的表都不见了:|现在这一直出现在日志中

< 2015-09-21 12:27:22.155 WIB >DEBUG:  performing replication slot checkpoint
< 2015-09-21 12:27:22.158 WIB >LOG:  request to flush past end of generated WAL; request 46/9E0981D8, currpos 46/771C69B0
< 2015-09-21 12:27:22.158 WIB >CONTEXT:  writing block 2 of relation base/18774/12766
< 2015-09-21 12:27:22.158 WIB >ERROR:  xlog flush request 46/9E0981D8 is not satisfied --- flushed only to 46/771C69B0
< 2015-09-21 12:27:22.158 WIB >CONTEXT:  writing block 2 of relation base/18774/12766
< 2015-09-21 12:27:22.158 WIB >WARNING:  could not write block 2 of base/18774/12766
< 2015-09-21 12:27:22.158 WIB >DETAIL:  Multiple failures --- write error might be permanent.

Answer 1

这是由损坏的行引起的。

创建一个函数来“检测”损坏的行:

CREATE OR REPLACE FUNCTION is_bad_row(tableName TEXT, tabName TEXT, tidInitial tid)
RETURNS integer 
as $find_bad_row$
BEGIN
    EXECUTE 'SELECT (each(hstore(' || tabName || '))).* FROM ' || tableName || ' WHERE ctid = $1' USING tidInitial; 
    RETURN 0;
    EXCEPTION
        WHEN OTHERS THEN
        RAISE NOTICE '% = %: %', tidInitial, SQLSTATE, SQLERRM;
        RETURN 1;
END
$find_bad_row$
LANGUAGE plpgsql;

...然后创建一个“临时表”来存储坏行的ctid:

create table bad_rows as 
SELECT ctid as row_tid
FROM your_schema.your_table
where is_bad_row('your_schema.your_table', 'your_table', ctid) = 1

...然后你只需要删除那些行:

delete from your_schema.your_table where ctid in (select row_tid from bad_rows)

...并删除“临时表”:

drop table bad_rows