华为云用户手册

问题现象 DROP TABLE失败的两种现象： 在使用“SELECT * FROM DBA_TABLES;”语句（或者gsql客户端也可以使用\dt+命令）查看数据库中无相关表；CREATE TABLE时报该表已经存在的错误，使用DROP TABLE语句失败，报不存在该表的错误，导致无法再次创建表。 在使用“SELECT * FROM DBA_TABLES;”语句（或者gsql客户端也可以使用\dt+命令）查看数据库中有相关表；使用DROP TABLE时失败，报不存在该表的错误，导致无法再次创建表。

处理方法 方法一：更改某个 GaussDB (DWS)集群的数据库默认时区。 登录GaussDB(DWS)管理控制台。 在左侧导航栏中，单击“集群管理”。 在集群列表中找到所需要的集群，单击集群名称，进入集群“基本信息”页面。 单击“参数修改”页签，修改参数“timezone”，修改为您所在的时区，然后单击“保存”。 在“修改预览”窗口，确认修改无误后，单击“保存”。 用户可根据界面中参数“timezone”所在行的“是否重启”列，判断修改参数后无需进行重启操作。 修改“timezone”参数后无需重启集群操作 ，则修改后立即生效。 方法二：通过后台命令查询和更改数据库时区。 查询客户端时区和当前时间。其中客户端时区为UTC时区，now()函数返回当前时间。 1 2 3 4 5 6 7 8 9 10 11 SHOW time zone; TimeZone ---------- UTC (1 row) select now(); now ------------------------------- 2022-05-16 06:05:58.711454+00 (1 row) 创建数据表，其中timestamp、timestamptz是常用的时间类型。timestamp不保存时区，timestamptz保存时区。 1 2 3 4 5 6 7 8 9 CREATE TABLE timezone_test (id int, t1 timestamp, t2 timestamptz) DISTRIBUTE BY HASH (id); \d timezone_test Table "public.timezone_test" Column | Type | Modifiers --------+-----------------------------+----------- id | integer | t1 | timestamp without time zone | t2 | timestamp with time zone | 向timezone_test表插入当前时间并查询当前表。 1 2 3 4 5 6 7 8 9 10 11 12 INSERT INTO timezone_test values (1, now(), now() ); show time zone; TimeZone ---------- UTC (1 row) SELECT * FROM timezone_test; id | t1 | t2 ----+----------------------------+------------------------------- 1 | 2022-05-16 06:10:04.564599 | 2022-05-16 06:10:04.564599+00 (1 row) t1（timestamp类型）在保存数据时丢弃了时区信息，t2（timestamptz类型）保存了时区信息。 把客户端时区设置为东8区（UTC-8），再次查询timezone_test表。 1 2 3 4 5 6 7 8 9 10 11 12 SET time zone 'UTC-8'; SHOW time zone; TimeZone ---------- UTC-8 (1 row) SELECT now(); now ------------------------------- 2022-05-16 14:13:43.175416+08 (1 row) 继续插入当前时间到timezone_test表，并查询。此时t1新插入的值是用的东8区时间，t2根据客户端时区对查询结果进行转换。 1 2 3 4 5 6 7 INSERT INTO timezone_test values (2, now(), now() ); SELECT * FROM timezone_test; id | t1 | t2 ----+----------------------------+------------------------------- 1 | 2022-05-16 06:10:04.564599 | 2022-05-16 14:10:04.564599+08 2 | 2022-05-16 14:15:03.715265 | 2022-05-16 14:15:03.715265+08 (2 rows) timestamp类型只受数据在插入时的时区影响，查询结果不受客户端时区影响。 timestamptz类型在数据插入时记录了时区信息，查询时会根据客户端时区做转换，以客户端时区显示数据。

问题现象 查看日志提示： [ERROR] Mpp task queryDataAnalyseById or updateDataAnalyseHistoryEndTimesAndResult fail, dataAnalyseId:17615 org.postgresql.util.PSQLException: ERROR: memory is temporarily unavailable sql：vacuum full dws_customer_360.t_user_resource;

操作场景 在日常作业开发中，数据库事务管理中的锁一般指的是表级锁，GaussDB(DWS)中支持的锁模式有8种，按排他级别分别为1~8。每种锁模式都有与之相冲突的锁模式，由锁冲突表定义相关的信息，锁冲突表如表1所示。 举例：用户u1对某张表test执行INSERT事务时，此时持有RowExclusiveLock锁；此时用户u2也对test表进行VACUUM FULL事务，则该事务与INSERT事务产生锁冲突，处于锁等待状态。 常用的锁等待检测主要通过查询视图pgxc_lock_conflicts、pgxc_stat_activity、pgxc_thread_wait_status、pg_locks进行。其中pgxc_lock_conflicts视图在8.1.x版本后支持，根据集群版本号不同，检测方式不同。

操作步骤 构造锁等待场景： 打开一个新的连接会话，使用普通用户u1连接GaussDB(DWS)数据库，在自己的同名SCHEMA u1下创建测试表u1.test。 1 CREATE TABLE test (id int, name varchar(50)); 开启事务1，进行INSERT操作。 1 2 START TRANSACTION; INSERT INTO test VALUES (1, 'lily'); 打开一个新的连接会话，使用系统管理员dbadmin连接GaussDB(DWS)数据库，执行VACUUM FULL操作，发现语句阻塞。 1 VACUUM FULL u1.test; 锁等待检测（8.1.x及以上版本） 打开一个新的连接会话，使用系统管理员dbadmin连接GaussDB(DWS)数据库，通过pgxc_lock_conflicts视图查看锁冲突情况。 如下图，回显中查看granted字段为“f”，表示VACUUM FULL语句正在等待其他锁。granted字段为“t”，表示INSERT语句是持有锁。nodename，表示锁产生在的位置，即CN或DN位置，例如cn_5001。 1 SELECT * FROM pgxc_lock_conflicts; 据语句内容确认是否中止持锁语句。如果终止，则执行以下语句。pid从1获取，cn_5001为上面查询到的nodename。 1 execute direct on (cn_5001) 'SELECT PG_TERMINATE_BACKEND(pid)'; 锁等待检测（8.0.x及以前版本） 在数据库中执行以下语句，获取VACUUM FULL操作对应的query_id。 1 SELECT * FROM pgxc_stat_activity WHERE query LIKE '%vacuum%'AND waiting = 't'; 根据获取的query_id，执行以下语句查看是否存在锁等待，并获取对应的tid。其中，{query_id}从1获取。 1 SELECT * FROM pgxc_thread_wait_status WHERE query_id = {query_id}; 回显中“wait_status”存在“acquire lock”表示存在锁等待。同时查看“node_name”显示在对应的CN或DN上存在锁等待，记录相应的CN或DN名称，例如cn_5001或dn_600x_600y。 执行以下语句，到等锁的对应CN或DN上通过查询pg_locks系统表查看VACUUM FULL操作在等待哪个锁。以下以cn_5001为例，如果在DN上等锁，则改为相应的DN名称。pid为2获取的tid。 回显中记录relation的值。 1 execute direct on (cn_5001) 'SELECT * FROM pg_locks WHERE pid = {tid} AND granted = ''f'''; 根据获取的relation，通过查询pg_locks系统表查看当前持有锁的pid。{relation}从3获取。 1 execute direct on (cn_5001) 'SELECT * FROM pg_locks WHERE relation = {relation} AND granted = ''t'''; 根据pid，执行以下语句，查到对应的SQL语句。{pid}从4获取。 1 execute direct on (cn_5001) 'SELECT query FROM pg_stat_activity WHERE pid={pid}'; 根据语句内容确认是中止持锁语句还是待持锁语句结束再重新执行VACUUM FULL。如果终止，则执行以下语句。pid从4获取。 中止结束后，再尝试重新执行VACUUM FULL。 1 execute direct on (cn_5001) 'SELECT PG_TERMINATE_BACKEND(pid)';

处理方法 方法一：检查数据冲突，修改插入数据。例如，修改示例重复字段UA502为UA509。 1 2 INSERT INTO films VALUES ('UA509', 'Bananas', 105, '1971-07-13', 'Comedy', '82 minutes'); INSERT 0 1 方法二：删除表films主键约束。 1 2 3 4 ALTER TABLE films DROP CONSTRAINT films_pkey; ALTER TABLE INSERT INTO films VALUES ('UA502', 'Bananas', 105, '1971-07-13', 'Comedy', '82 minutes'); INSERT 0 1

问题现象 向表中插入数据报错：duplicate key value violates unique constraint "%s"。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 CREATE TABLE films ( code char(5) PRIMARY KEY, title varchar(40) NOT NULL, did integer NOT NULL, date_prod date, kind varchar(10), len interval hour to minute ); NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "films_pkey" for table "films" CREATE TABLE INSERT INTO films VALUES ('UA502', 'Bananas', 105, DEFAULT, 'Comedy', '82 minutes'); INSERT INTO films VALUES ('UA502', 'Bananas', 105, '1971-07-13', 'Comedy', '82 minutes'); ERROR: dn_6003_6004: duplicate key value violates unique constraint "films_pkey" DETAIL: Key (code)=(UA502) already exists.

处理方法 这两种行为由参数behavior_compat_options控制，当参数behavior_compat_options缺省的情况下，匹配到多行会报错，如果behavior_compat_options设置了merge_update_multi参数项，这种情况下不会报错，而是会随机匹配一行数据。 因此，当出现MERGE INTO的结果与预期不符时，需查看该参数是否被设置，同时排查是否匹配了多行数据，并修改业务逻辑。

原因分析 增加分区时需同时满足以下条件： 新增分区名不能与已有分区名相同。 新增分区的边界值必须大于最后一个分区的上边界。 新增分区的边界值要和分区表的分区键的类型一致。 已有分区p1的边界为(-∞，20221010)，而新增分区p0的上边界为20221009，落在分区p1内；已有分区p4的边界为[20221012,+∞)，而新增分区p5的上界为20221013，落在分区p4内。新增分区p0、p5不满足使用ADD PARTITION增加分区的条件，因此执行新增分区语句报错。

处理方法 使用ALTER TABLE SPLIT PARTITION分割已有分区，也能达到新增分区的目的。同样， SPLIT PARTITION的新分区名称也不能与已有分区相同。 使用split子句分割p4分区[20221012,+∞)为p4a分区范围为[20221012,20221013)和p4b分区范围为[20221013,+∞)。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 ——SPLIT PARTITION分割前的分区 SELECT relname, boundaries FROM pg_partition p where p.parentid='studentinfo'::regclass ORDER BY 1; relname | boundaries -------------+------------------------- p1 | {"2022-10-10 00:00:00"} p2 | {"2022-10-11 00:00:00"} p3 | {"2022-10-12 00:00:00"} p4 | {NULL} studentinfo | (5 rows) ALTER TABLE studentinfo SPLIT PARTITION p1 AT('2022-10-09 00:00:00+08') INTO (PARTITION P1a,PARTITION P1b); ALTER TABLE studentinfo SPLIT PARTITION p4 AT('2022-10-13 00:00:00+08') INTO (PARTITION P4a,PARTITION P4b); ——执行SPLIT PARTITION分割后的分区 SELECT relname, boundaries FROM pg_partition p where p.parentid='studentinfo'::regclass ORDER BY 1; relname | boundaries -------------+------------------------- p1a | {"2022-10-09 00:00:00"} p1b | {"2022-10-10 00:00:00"} p2 | {"2022-10-11 00:00:00"} p3 | {"2022-10-12 00:00:00"} p4a | {"2022-10-13 00:00:00"} p4b | {NULL} studentinfo | (7 rows) 如果对分区名称有要求，可以在分割后再使用rename partition统一分区名。 ALTER TABLE studentinfo RENAME PARTITION p1a to p0;

问题现象 创建范围分区表后增加新的分区，使用ALTER TABLE ADD PARTITION语句报错upper boundary of adding partition MUST overtop last existing partition。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 ——创建范围分区表studentinfo CREATE TABLE studentinfo (stuno smallint, sname varchar(20), score varchar(20), examate timestamp) PARTITION BY RANGE (examate) ( PARTITION p1 VALUES LESS THAN ('2022-10-10 00:00:00+08'), PARTITION p2 VALUES LESS THAN ('2022-10-11 00:00:00+08'), PARTITION p3 VALUES LESS THAN ('2022-10-12 00:00:00+08'), PARTITION p4 VALUES LESS THAN (maxvalue) ); ——添加边界值为2022-10-9 00:00:00+08的分区p0 ALTER TABLE studentinfo ADD PARTITION p0 values less than ('2022-10-9 00:00:00+08'); ERROR: the boundary of partition "p0" is less than previous partition's boundary ——添加边界值为2022-10-13 00:00:00+08的分区p5 ALTER TABLE studentinfo ADD PARTITION p5 values less than ('2022-10-13 00:00:00+08'); ERROR: the boundary of partition "p5" is equal to previous partition's boundary

问题现象 数据库中新建一张表，某个表字段使用character类型，在Java中读取character类型的字段时返回类型是byte。 例如，创建示例表table01： 1 2 3 4 CREATE TABLE IF NOT EXISTS table01( msg_id character(36), msg character varying(50) ); 在Java中，读取character类型的字段代码如下： 1 ColumnMetaInfo(msg_id,1,Byte,true,false,1,true);

问题现象 DWS中有两种情况需要关注表是否做过UPDATE及DELETE操作： 对表频繁执行UPDATE或者DELETE操作会产生大量的磁盘页面碎片，从而逐渐降低查询的效率，需要将磁盘页面碎片恢复并交还操作系统，即VACUUM FULL操作，这种场景下需要查找出哪些表执行过UPDATE； 判断一张表是否是维度表，是否可以从Hash表变更为复制表，可以查看这张表是否执行过UPDATE或DELETE，如果执行过UPDATE或DELETE操作，则不能修改为复制表。

处理方法 通过以下命令查找哪些表执行过UPDATE及DELETE操作： 1 2 3 4 5 6 7 8 9 ANALYZE tablename; SELECT n.nspname , c.relname, pg_stat_get_tuples_deleted(x.pcrelid) as deleted, pg_stat_get_tuples_updated(x.pcrelid) as updated FROM pg_class c INNER JOIN pg_namespace n ON n.oid = c.relnamespace INNER JOIN pgxc_class x ON x.pcrelid = c.oid WHERE c.relkind = 'r' and c.relname='tablename' ;

处理方法 删除该表索引信息。 1 DROP INDEX a_0317_index; 对该表索引进行重建。 1 CREATE INDEX a_0317_index on a_0317(a) local (partition p1_index, partition p2_inde); 查看表定义无报错。 1 2 3 4 5 6 7 8 9 10 11 12 13 \d+ a_0317 Table "public.a_0317" Column | Type | Modifiers | Storage | Stats target | Description --------+---------+-----------+---------+--------------+------------- a | integer | | plain | | Indexes: "a_0317_index" btree (a) LOCAL(PARTITION p1_index, PARTITION p2_inde) TABLESPACE pg_default Range partition by(a) Number of partition: 2 (View pg_partition to check each partition range.) Has OIDs: no Distribute By: HASH(a) Location Nodes: ALL DATANODES Options: orientation=row, compression=no

问题复现 创建分区表a_0317，含p1，p2两个分区。 1 CREATE TABLE a_0317(a int) partition by range(a) (partition p1 values less than (4), partition p2 values less than (8)); 创建主表与分区索引。 1 CREATE INDEX a_0317_index on a_0317(a) local (partition p1_index, partition p2_inde); 查看分区表分区索引信息如下： 查看主表索引信息。 1 2 3 4 5 6 7 8 9 10 11 SELECT oid,* FROM pg_class where relname ='a_0317_index'; oid | relname | relnamespace | reltype | reloftype | relowner | relam | relfilenode | reltablespace | relpages | reltuples | relallvisible | reltoastrelid | reltoastidxid | reldeltarelid | reld eltaidx | relcudescrelid | relcudescidx | relhasindex | relisshared | relpersistence | relkind | relnatts | relchecks | relhasoids | relhaspkey | relhasrules | relhastriggers | relhassubclass | relcmprs | relhasclusterkey | relrowmovement | parttype | relfrozenxid | relacl | reloptions | relreplident | relfrozenxid64 --------+--------------+--------------+---------+-----------+----------+-------+-------------+---------------+----------+-----------+---------------+---------------+---------------+---------------+----- --------+----------------+--------------+-------------+-------------+----------------+---------+----------+-----------+------------+------------+-------------+----------------+----------------+--------- -+------------------+----------------+----------+--------------+--------+------------+--------------+---------------- 241487 | a_0317_index | 2200 | 0 | 0 | 16393 | 403 | 241487 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | f | f | p | i | 1 | 0 | f | f | f | f | f | 0 | f | f | p | 0 | | | n | 0 (1 row) 根据主表索引信息查看分区索引信息。 1 2 3 4 5 6 7 8 9 10 SELECT * FROM pg_partition where parentid= 241487; relname | parttype | parentid | rangenum | intervalnum | partstrategy | relfilenode | reltablespace | relpages | reltuples | relallvisible | reltoastrelid | reltoastidxid | indextblid | indisusable | reldeltarelid | reldeltaidx | relcudescrelid | relcudescidx | relfrozenxid | intspnum | partkey | intervaltablespace | interval | boundaries | transit | reloptions | relfrozenxid64 ----------+----------+----------+----------+-------------+--------------+-------------+---------------+----------+-----------+---------------+---------------+---------------+------------+-------------+- --------------+-------------+----------------+--------------+--------------+----------+---------+--------------------+----------+------------+---------+------------+---------------- p1_index | x | 241487 | 0 | 0 | n | 241488 | 0 | 0 | 0 | 0 | 0 | 0 | 241485 | t | 0 | 0 | 0 | 0 | 0 | | | | | | | | 0 p2_inde | x | 241487 | 0 | 0 | n | 241489 | 0 | 0 | 0 | 0 | 0 | 0 | 241486 | t | 0 | 0 | 0 | 0 | 0 | | | | | | | | 0 (2 rows) 连接CN开启读写事务，从pg_partition系统表删除p1分区的索引信息。 1 2 START TRANSACTION read write; DELETE from pg_partition where relname = 'p1_index'; 查看表定义报错与现场报错相同，问题复现： 1 2 \d+ a_0317 ERROR: The local index 700633 on the partition 700647 not exist.CONTEXT: referenced column: pg_get_indexdef

解决办法 为防止出现分区间隙，需要将ADD PARTITION的START值前移。 以分区表partitiontest为例： 1 2 3 4 5 6 7 8 9 10 CREATE TABLE partitiontest ( c_int integer, c_time TIMESTAMP WITHOUT TIME ZONE ) PARTITION BY range (c_int) ( partition p1 start(100)end(108), partition p2 start(108)end(120) ); 执行如下两种语句会发生报错： 1 2 ALTER TABLE partitiontest ADD PARTITION p3 start(120)end(130), DROP PARTITION p2; ERROR: start value of partition "p3" NOT EQUAL up-boundary of last partition. 1 2 ALTER TABLE partitiontest DROP PARTITION p2,ADD PARTITION p3 start(120)end(130); ERROR: start value of partition "p3" NOT EQUAL up-boundary of last partition. 可以修改语句为： 1 ALTER TABLE partitiontest ADD PARTITION p3 start(108)end(130), DROP PARTITION p2; 1 ALTER TABLE partitiontest DROP PARTITION p2,ADD PARTITION p3 start(108)end(130);

处理方法 方法一 该处理方法仅8.1.3及以上集群版本支持。 登录GaussDB(DWS) 管理控制台。 在集群列表中单击指定集群名称。 进入“集群详情”页面，切换至“智能运维”页签。 在运维详情部分切换至运维计划模块。单击“添加运维任务”按钮。 弹出添加运维任务边栏。 运维任务选择“Vacuum”。 调度模式选择“指定目标”，智能运维将在指定时间窗内，自动下发表级Vacuum任务。 用户可配置需要Vacuum的列存表，其中一行对应一张表，每张表以数据库名、模式名、表名表示，以空格进行分割。 单击“下一步：定时配置”，配置Vacuum类型，推荐选择“周期型任务”，GaussDB(DWS)将自动在自定义时间窗内执行Vacuum。 确认无误后，单击“下一步：配置确认”，完成配置。 方法二 对列存表更新操作后，需要进行VACUUM FULL清理，更多用法请参见VACUUM的“VACUUM”章节的“VACUUM”章节。 1 VACUUM FULL table_name;

解决办法 通过下列的操作步骤，可以分析出查询效率异常降低的原因。 使用ANALYZE命令分析数据库。 ANALYZE命令更新所有表中数据大小以及属性等相关统计信息，该命令较为轻量级，可以经常执行。如果此命令执行后性能恢复或者有所提升，则表明AUTOVACUUM未能很好的完成它的工作，有待进一步分析。 检查查询语句是否返回了多余的数据信息。 例如，如果查询语句先查询一个表中所有的记录，而只用到结果中的前10条记录。对于包含50条记录的表，查询起来是很快的；但是，当表中包含的记录达到50000，查询效率将会有所下降。 若业务应用中存在只需要部分数据信息，但是查询语句却是返回所有信息的情况，建议修改查询语句，增加LIMIT子句来限制返回的记录数。这样至少使数据库优化器有了一定的优化空间，一定程度上会提升查询效率。 检查查询语句单独运行时是否仍然较慢。 尝试在数据库没有其他查询或查询较少的时候运行查询语句，并观察运行效率。如果效率较高，则说明可能是由于之前运行数据库系统的主机负载过大导致查询低效。此外，还可能是由于执行计划比较低效，但是由于主机硬件较快使得查询效率较高。 检查重复相同查询语句的执行效率。 查询效率低的一个重要原因是查询所需信息没有缓存在内存中，这可能是由于内存资源紧张，缓存信息被其他查询处理覆盖。 重复执行相同的查询语句，如果后续执行的查询语句效率提升，则可能是由于上述原因导致。

原因分析 网络不通 如果客户端主机通过GaussDB(DWS)集群的内网地址进行连接，需要排查客户端主机跟GaussDB(DWS)集群是否在相同的VPC和子网内，如果不在相同的VPC和子网内，则网络不通。 安全组规则禁止ping GaussDB(DWS)集群所属的安全组入规则需要放开ICMP协议端口才能允许ping，如果未开放ICMP协议端口，就无法ping通。创建GaussDB(DWS)集群时自动创建的安全组默认只放开了TCP协议和8000端口。 如果安全组入规则已开放ICMP协议端口，需要检查相应入规则的源地址是否涵盖了客户端主机的IP地址，如果没有，也无法ping通。

处理方法 网络不通 如果客户端主机通过GaussDB(DWS)集群的内网地址进行连接，应重新申请一台弹性云服务器作为客户端主机，且该弹性云服务器必须和GaussDB(DWS)集群处于相同的VPC和子网内。 安全组规则禁止ping 检查GaussDB(DWS)集群所属的安全组规则，查看是否对客户端主机的IP地址开放了ICMP协议端口。具体操作如下： 登录GaussDB(DWS)管理控制台。 在“集群管理”页面，找到所需要的集群，单击集群名称进入“基本信息”页面。 在“基本信息”页面，找到“安全组”参数，单击安全组名称，进入相应的安全组详情页面。 进入“入方向规则”页签，检查是否存在开放ICMP协议端口的入规则，如果不存在，请单击“添加规则”按钮，添加入方向规则开放ICMP协议端口。 协议端口：选择“ICMP”和“全部”。 源地址：选择“IP地址”，然后根据客户端主机的IP地址输入相应的IP地址与掩码。0.0.0.0/0表示任意地址。 图1 入方向规则 单击“确定”，完成入规则的添加。

原因分析 GDS进程崩溃。执行命令检查GDS进程是否崩溃： ps ux|grep gds 如果返回结果如下，则说明GDS进程启动成功： GDS启动参数-H配置不正确。 -H address_string：允许哪些主机连接和使用GDS服务。参数需为CIDR格式。此参数配置的目的是允许GaussDB(DWS)集群可以访问GDS服务进行数据导入，请保证所配置的网段包含GaussDB(DWS)集群各主机。

分析过程 和用户确认部分业务慢，执行慢的业务中都涉及到了同一张表tb_motor_vehicle。 收集几个典型的慢SQL语句，分别打印执行计划。从执行计划中可以看出来，两条SQL的耗时都集中在Partitioned CS tore Scan on public.tb_motor_vehicle列存表的分区扫描上。 已确认该表的分区键为createtime，而涉及的SQL中无任何createtime的筛选和过滤条件，基本可以确认是由于慢SQL的计划没有走分区剪枝，导致了全表扫描，对于185亿条数据量的表，全表扫描性能会很差。

原因分析 上述问题中撤销user3对表t1的访问权限未生效是因为：之前执行过GRANT SELECT ON table t1 TO public;这条SQL语句，该语句中关键字public表示该权限要赋予给所有角色，包括之后新创建的角色，所以新用户user3对该表也有访问权限。public可以看做是一个隐含定义好的组，它包含所有角色。 因此，执行完REVOKE SELECT ON table t1 FROM user3;之后，虽然user3用户没有了表t1的访问权限（通过系统表pg_class的relacl字段可查看t1表的权限），但是他仍然有public的权限，所以仍能访问该表。

调用存储过程报错 ERROR: cached plan must not change result type 问题分析：由于JDBC中使用了PreparedStatement，默认重复执行5次就会缓存plan，在此之后有如果重建表操作（例如修改表定义），再次执行就会报错ERROR: cached plan must not change result type. 处理方法：在JDBC连接字串中指定prepareThreshold=0，不再cache plan。例如： 1 String url = "jdbc:postgresql:// 192.168.0.10:2000/postgres?prepareThreshold=0";

使用JDBC执行create table as 语句报错 ERROR: relation "xx" already exists 问题分析：JDBC调用preparedStatement.getParameterMetaData()时会发送P报文，该报文会在数据库中创建表，导致execute执行时报表已存在。 处理方法：使用preparedStatement时，建议将CREATE TABLE AS拆开执行或者使用resultSet.getMetaData()。

Broken pipe, connection reset by peer 问题分析：网络故障，数据库连接超时。 处理方法：检查网络状态，修复网络故障，影响数据库连接超时的因素。例如，数据库参数session_timeout。 登录控制台单击指定集群名称。 在左侧导航栏选择“参数修改”，搜索参数“session_timeout”查看超时时间参数。 将session_timeout的CN、DN参数值设置为0，详情可参见修改数据库参数。

处理方法 8.0以下版本集群清理系统表需要先执行DELETE FROM，再执行VACUUM FULL。 此处仅以gs_wlm_session_info系统表为例： 1 2 DELETE FROM pg_catalog.gs_wlm_session_info; VACUUM FULL pg_catalog.gs_wlm_session_info; 8.0及以上版本集群可执行以下命令清理系统表： 1 TRUNCATE TABLE dbms_om.gs_wlm_session_info; 此系统表的schema是dbms_om。

解决方案 建议根据业务实际情况调整update语句。比如分析public.t2的字段含义，确定更新的目标字段。针对上述案例，如果期望在a值相等的情况下，把public.t1中字段b更新为public.t2中的最大值，那么可以修改为如下逻辑： 1 2 3 4 5 6 7 UPDATE t1 SET t1.b = t2.b_max FROM (SELECT a, max(b) AS b_max FROM t2 GROUP BY a) t2 WHERE t1.a = t2.a; UPDATE 1 SELECT * FROM public.t1; a | b ---+--- 1 | 2 (1 row)

原因分析 当一条SQL语句中同一个元组被多次更新，执行便会报错ERROR：Non-deterministic UPDATE。 可以看到更新操作分成两步执行： 通过关联操作查找满足更新条件的元组。 执行更新操作。 针对上述案例，对于表public.t1中元组 (1, 1)来说，表public.t2中满足更新条件t1.a = t2.a的记录有两条，分别为(1, 1)， (1, 2)；按照执行器逻辑表t2的元组 (1, 1)需要被更新两次，那么就可能出现两种情况： 表public.t1和表public.t2关联时先命中(1, 1)，再命中(1, 2)，这时public.t1的元组(1, 1)，先被更新为(1,1)，再被更新为(1,2)，最终结果为(1, 2)。 表public.t1和表public.t2关联时先命中(1, 2)，再命中(1, 1)，这时public.t1的元组(1, 1)，先被更新为(1,2)，再被更新为(1,1)，最终结果为(1, 1)。 实际执行过程中public.t2表输出结果集的顺序会影响update语句的最终输出结果（实际业务中表public.t2的位置可能是一个非常复杂的子查询），导致了update语句执行结果的随机性，而这个实际业务中是无法接受的。