Greenplum gp_vmem_protect_limit 出错

运行的Greenplum报这个错:

‘53400’, ‘[53400] ERROR: Out of memory  (seg30 slice3 bbsod:40002 pid=26372)\\\\nVM Protect failed to allocate 8388608 bytes, 6 MB available;\\\\nError while executing the query (7)
psql进入查看show gp_vmem_protect_limit 为8096,单位是kb。重设这个参数: gpconfig -c gp_vmem_protect_limit -v 1048576并记住要重启服务gpstop -r

Greenplum集群挂掉后启动

环境:CentOS 5.7,  Greenplum database 4.1
昨天不知怎样原因Greenplum集群中某台segment server挂掉,造成整个集群数据无法查看,报错为“error failed to acquire resources on one or more segments”。后来使用gpstop关掉尝试重新启动却无法成功。 使用debug模式启动: gpstart -v ,最终发现这个segment server的文件/dev/urandom权限为crw——-造成无法读取和写入。最后修改文件权限chmod go+rwx

Greenplum存储过程使用分区表将进行全表扫描

环境:Greenplum Database 4.2.1.0 , RHEL 5.4
问题: 之前用存储过程转换数据,其中一个表做分区,里面的逻辑先是删除日期参数的数据,然后用外部表导入再转换。最近由于装载了很多数据,发现后续增量加载超慢。 后来发现是“删除日期参数的数据”这个操作造成的,删除某一天数据执行的是全表扫描。但在psql命令中分区键能过滤。
解决方法: 在网上找到一篇跟我碰到情况类似的
大意是有两种方式避免,1. 涉及分区表使用动态sql   2. 升级至postgresql 9.2  , 这两种方法显能对gp是不靠谱的,只能用动态sql了, 苦了我们这帮用存储过程做数据转换的开发者。

Postgres-XC单机安装

单机环境: CentOS 6 64bit,  pgxc-v1.0.1.tar.gz
解压 pgxc-v1.0.1.tar.gz,进入pgxc,
 ./configure –without-readline –without-zlib    ( 注:由于服务器未安装readline和zlib包,故省去)
gmake
gmake install
安装协调结点,数据结点和GTM,
cd /usr/local/pgsql/bin/
./initdb -D /usr/local/pgsql/data_coord1 –nodename coord1
./initdb -D /usr/local/pgsql/data_datanode1 –nodename datanode1
./initdb -D /usr/local/pgsql/data_datanode2 –nodename datanode2
./initgtm -D /usr/local/pgsql/data_gtm -Z gtm
启动服务:
./gtm -D /usr/local/pgsql/data_gtm &
./postgres -X -p 15432 -D /usr/local/pgsql/data_datanode1 &
./postgres -X -p 15433 -D /usr/local/pgsql/data_datanode2 &
./postgres -C -D /usr/local/pgsql/data_coord1 &
进入postgres-xc,创建元数据
./psql
create node datanode1 with(type=’datanode’, port=15432);
create node datanode2 with(type=’datanode’, port=15433);
select pgxc_pool_reload();
./createdb test
创建测试数据库
./psql test
create table user_info_hash(id int primary key,firstname text,lastname text,info text) distribute by hash(id) to node datanode1,datanode2;
insert into user_info_hash select generate_series(1,10000),’zhou’,’digoal’,’DBA’;