华为云用户手册

处理方法 当字符串表达式中collation有多个时，可手动指定COLLATE collation_name。 执行SELECT时，指定表达式ifnull(a,b)的排序规则为C或者case_insensitive。 1 2 3 4 5 6 7 8 91011 SELECT hashtext(ifnull(a,b) collate "C") FROM t; hashtext----------- 820977155(1 row)SELECT hashtext(ifnull(a,b) collate case_insensitive) FROM t; hashtext----------- 238052143(1 row)

解决方案 方案一：设置参数behavior_compat_options为merge_update_multi。 当目标表匹配到多行满足条件时，该方案不会报错，而是会随机匹配一行数据，有数据遗漏风险。 1 2 3 4 5 6 7 8 910111213141516 SET behavior_compat_options=merge_update_multi;MERGE INTO products p USING newproducts np ON (p.product_id = np.product_id) WHEN MATCHED THEN UPDATE SET p.product_name = np.product_name, p.category = np.category WHERE np.product_id = 1502;MERGE 1SELECT * FROM products ; product_id | product_name | category------------+----------------+----------- 1501 | vivitar 35mm | electrncs 1502 | olympus camera | electrncs 1600 | play gym | toys(3 rows) 方案二：修改MERGE INTO匹配条件。 尽可能选择筛选结果唯一的表达式为匹配条件。 1 2 3 4 5 6 7 8 91011121314 MERGE INTO products p USING newproducts np ON (p.product_id = np.product_id) WHEN MATCHED THEN UPDATE SET p.product_name = np.product_name, p.category = np.category WHERE np.product_id != 1502;MERGE 1SELECT * FROM products; product_id | product_name | category------------+----------------+----------- 1501 | vivitar 35mm | electrncs 1502 | olympus camera | electrncs 1600 | lamaze | toys(3 rows)

原因分析 源表newproducts中product_id为1502的数据有两条，且参数behavior_compat_options缺省，因此MERGE INTO时匹配到多条数据报错。 MERGE INTO的作用是将源表内容根据匹配条件对目标表做更新或插入，当目标表匹配到多行满足条件时， GaussDB (DWS)有以下两种行为： 业务报错：unable to get a stable set of rows in the source table。 随机匹配一行数据，可能会导致实际与预期不符。 这两种行为由参数behavior_compat_options控制，当参数behavior_compat_options缺省的情况下，匹配到多行会报错，如果behavior_compat_options被设置为merge_update_multi，则不会报错，而是会随机匹配一行数据。 因此，当出现merge into的结果与预期不符的情况时，需查看该参数是否被设置，同时排查是否匹配了多行数据，并根据实际情况修改业务逻辑。

问题现象 执行MERGE INTO将源表内容根据匹配条件对目标表做更新报错unable to get a stable set of rows in the source table。 现有目标表products和源表newproducts，以源表newproducts中product_id为1502为匹配条件，对目标表进行更新报错： 1 2 3 4 5 6 7 8 91011121314 CREATE TABLE products (product_id INTEGER,product_name VARCHAR2(60),category VARCHAR2(60));INSERT INTO products VALUES (1501, 'vivitar 35mm', 'electrncs'),(1502, 'olympus is50', 'electrncs'),(1600, 'play gym', 'toys');CREATE TABLE newproducts (product_id INTEGER,product_name VARCHAR2(60),category VARCHAR2(60));INSERT INTO newproducts VALUES (1502, 'olympus camera', 'electrncs'),(1600, 'lamaze', 'toys'),(1502, 'skateboard', 'toy');MERGE INTO products p USING newproducts np ON (p.product_id = np.product_id) WHEN MATCHED THEN UPDATE SET p.product_name = np.product_name, p.category = np.category WHERE np.product_id = 1502;ERROR: dn_6003_6004: unable to get a stable set of rows in the source tables

解决方案 建议根据业务实际情况调整update语句。比如分析public.t2的字段含义，确定更新的目标字段。针对上述案例，如果期望在a值相等的情况下，把public.t1中字段b更新为public.t2中的最大值，那么可以修改为如下逻辑： 1234567 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 1SELECT * 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语句执行结果的随机性，而这个实际业务中是无法接受的。

处理方法 场景一：语句估算内存过大，造成排队。 查询pg_session_wlmstat视图，查看状态为running的语句是否个数很少，而且statement_mem字段数值是否较大（单位为MB，一般认为大于max_dynamic_memory 1/3即为大内存语句）。如果都符合就可以判断是此类语句占据内存导致整体运行缓慢。 1 SELECT usename,substr(query,0,20),threadid,status,statement_mem FROM pg_session_wlmstat where usename not in ('omm','Ruby') order by statement_mem,status desc; 如上图所示，只有最后一个语句是running状态，其余语句都是pending状态。根据statement_mem可以看到该语句占据2576MB内存。此时根据语句的threadid，执行以下命令终止对应的查询语句，终止后即可释放资源，其余语句正常运行。 1 SELECT pg_terminate_backend(threadid); 场景二：所有语句状态都是pending状态，没有运行的语句。此时应是管控机制出现异常，直接终止所有线程，即可恢复正常。 1 SELECT pg_terminate_backend(pid) FROM pg_stat_activity where usename not in ('dbadmin','Ruby');

问题现象 执行update语句报错ERROR：Non-deterministic UPDATE。 1 2 3 4 5 6 7 8 9101112 CREATE TABLE public.t1(a int, b int) WITH(orientation = column);CREATE TABLECREATE TABLE public.t2(a int, b int) WITH(orientation = column);CREATE TABLEINSERT INTO public.t1 VALUES (1, 1);INSERT INTO public.t2 VALUES (1, 1),(1, 2);UPDATE t1 SET t1.b = t2.b FROM t2 WHERE t1.a = t2.a;ERROR: Non-deterministic UPDATEDETAIL: multiple updates to a row by a single query for column store table.

处理方法 应根据数据实际情况规划分区，以保证插入的数据都在规划好的分区中。 如果已规划的分区无法满足实际应用条件，可以增加分区后再插入数据。针对上述案例，可以增加分区c2，分区范围介于5000和MAXVALUE之间： 1 2 3 4 5 6 7 8 9101112131415161718192021222324 ALTER TABLE startend_pt ADD PARTITION P6 VALUES LESS THAN (MAXVALUE);SELECT partition_name,high_value FROM dba_tab_partitions WHERE table_name='startend_pt'; partition_name | high_value----------------+------------ p1_0 | 1 p1_1 | 201 p1_2 | 401 p1_3 | 601 p1_4 | 801 p1_5 | 1000 p2 | 2000 p3 | 2500 p4 | 3000 p5_1 | 4000 p5_2 | 5000 p6 | MAXVALUE(12 rows)INSERT INTO startend_pt VALUES (1,5001);SELECT * FROM startend_pt; c1 | c2----+------ 1 | 5001(1 row)

处理方法 建议开启列存表的delta表功能。 1 ALTER TABLE table_name SET (ENABLE_DELTA = ON); 开启列存表的delta表功能，在导入单条或者小规模数据进入表中时，能够防止小CU的产生，所以开启delta表能够带来显著的性能提升，例如在3CN、6DN的集群上操作，每次导入100条数据，导入时间能减少25%，存储空间减少97%，所以在需要多次插入小批量数据前应该先开启delta表，等到确定接下来没有小批量数据导入了再关闭。 delta表就是列存表附带的行存表，那么将数据插入delta表后将失去列存表的高压缩比等优势，正常情况下使用列存表的场景都是大批量数据导入，所以默认关闭delta表，如果开启delta表做大批量数据导入，反而会额外消耗更多时间和空间，同样在3CN、6DN的集群上操作，每次导入10000条数据时，开启delta表会比不开启时慢4倍，额外消耗10倍以上的空间。所以开启delta表需谨慎，根据实际业务需要来选择开启和关闭。

问题现象 给范围分区表插入数据报错：inserted partition key does not map to any table partition。 1 2 3 4 5 6 7 8 9101112131415161718192021222324252627 CREATE TABLE startend_pt (c1 INT, c2 INT) DISTRIBUTE BY HASH (c1) PARTITION BY RANGE (c2) ( PARTITION p1 START(1) END(1000) EVERY(200) , PARTITION p2 END(2000), PARTITION p3 START(2000) END(2500) , PARTITION p4 START(2500), PARTITION p5 START(3000) END(5000) EVERY(1000) );SELECT partition_name,high_value FROM dba_tab_partitions WHERE table_name='startend_pt'; partition_name | high_value----------------+------------ p1_0 | 1 p1_1 | 201 p1_2 | 401 p1_3 | 601 p1_4 | 801 p1_5 | 1000 p2 | 2000 p3 | 2500 p4 | 3000 p5_1 | 4000 p5_2 | 5000(11 rows)INSERT INTO startend_pt VALUES (1,5001);ERROR: dn_6003_6004: inserted partition key does not map to any table partition

问题现象 场景一：执行VACUUM FULL时报错“Can't fit xid into page, now xid is 34181619720, base is 29832807366, min is 3, max is 3.”。 场景二：其他非VACUUM FULL操作，例如业务场景中给用户赋予函数的操作权限时，报错信息“Can't fit xid into page. relation "pg_proc", now xid is 34181619720, base is 29832807366, min is 3, max is 3.”。

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

处理方法 可在GaussDB(DWS)管理控制台设置告警的触发条件，指定达到磁盘使用率、告警持续时间及告警频次。 集群磁盘使用率达到90%就会触发集群只读，需要预留时间来处理问题，避免使用率达到只读阈值。 登录GaussDB(DWS) 管理控制台。 在左侧导航栏，单击“告警管理”，切换至“告警”页签。 单击左上角的“查看告警规则”按钮，进入告警规则页面。 在指定告警规则名称所在行操作列，单击“修改”按钮进入修改告警规则页面。将触发条件修改为平均值大于90%，抑制条件修改为“每1天告警一次”。（此处仅做举例，实际情况以业务诉求为准。） 触发条件：定义对监控指标做阈值判断的计算规则。目前主要使用一段时间内的平均值来降低告警震荡的几率。 抑制条件：在指定的时间段内，抑制同类型告警的反复触发和消除。 图1 设置告警规则

在modifyJdbcCall和createParameterizedQuery阶段耗时 问题分析：如果主要耗时在modifyJdbcCall阶段（校验传入的SQL是否符合规范）和createParameterizedQuery阶段（将传入的SQL解析为preparedQuery，以获取由simplequery组成的subqueries），则需要确认是否传入的SQL过长导致。 处理方法：JDBC本身没办法优化这部分耗时，可在应用端查看是否可优化传入的SQL语句，详情可参见SQL语句改写规则。

处理方法 要删除的用户为一个数据库的owner，需要将对象的所有权重新分配给其他用户。有以下两种处理方法： 方式一：将数据库owner转移给其他用户。例如，使用ALTER语句将数据库testdb的owner用户u1修改为u2。 12345678 testdb=# ALTER DATABASE testdb OWNER to u2;ALTER DATABASEtestdb=# \l List of databases Name | Owner | Encoding | Collate | Ctype | Access privileges -----------+----------+----------+-------------+-------------+------------------------- testdb | u2 | UTF8 | en_US.UTF-8 | en_US.UTF-8 |(4 rows) 执行删除u1用户的命令，不再提示“owner of database testdb”的信息。 123 testdb=# DROP USER u1;ERROR: role "u1" cannot be dropped because some objects depend on it DETAIL: 3 objects in database gaussdb 方式二：如果已确认不需要数据库testdb，也可直接将其删除。将所有u1拥有的数据库对象的属主更改为u2。 12 testdb=# REASSIGN OWNED BY u1 TO u2;REASSIGN OWNED 清理owner是u1的对象。请谨慎使用，会将用户同名的schema也一同清理掉。 12 testdb=# DROP OWNED by u1;DROP OWNED 要删除的用户存在依赖关系，需要解除依赖关系。处理方法如下： 识别依赖关系。根据报错信息“3 objects in database gaussdb”可知gaussdb数据库里有3个对象依赖u1。由于数据库内系统表的依赖，在其他数据库中不会打印出详细的依赖对象信息，那么在gaussdb库中执行DROP USER的时候，会打印出具体的信息。 连接到gaussdb库执行如下命令： 1234 gaussdb=# DROP USER u1;ERROR: role "u1" cannot be dropped because some objects depend on itDETAIL: privileges for table pg_classprivileges for schema u2 获取到依赖项的详细信息如下： privileges for table pg_class：pg_class上u1用户的权限。 schema u2上u1用户的权限。 撤销依赖对象的权限。 1 2 3 4 5 6 7 8 9101112131415 gaussdb=# SELECT relname,relacl FROM pg_class WHERE relname = 'pg_class'; relname | relacl----------+---------------------------------- pg_class | {=r/Ruby,u1=r/Ruby}(1 row)gaussdb=#SELECT nspname,nspacl FROM pg_namespace WHERE nspname = 'u2'; nspname | nspacl---------+----------------------------- u2 | {u2=UC/u2,u2=LP/u2,u1=U/u2}gaussdb=# REVOKE SELECT ON TABLE pg_class FROM u1;REVOKEgaussdb=# REVOKE USAGE ON SCHEMA u2 FROM u1;REVOKE 再删除用户，可成功删除，不再提示有依赖。 12 gaussdb=# DROP USER u1;DROP USER

问题现象 数据库使用中遇到某些用户离职或者角色变更时，要对其账号进行销户、权限进行回收等操作，但是删除用户时出现类似：role “u1” cannot be dropped because some objects depend on it的报错信息，无法删除该用户。 例如，要删除用户u1时，出现如下提示： 1234 testdb=# DROP USER u1;ERROR: role "u1" cannot be dropped because some objects depend on it DETAIL: owner of database testdb 3 objects in database gaussdb

原因分析 两个不同的事务对同一个表中的同一行数据进行并发更新/操作，导致后操作的事务发生了回滚。 举例说明： 打开一个连接Session A，使用普通用户u1连接GaussDB(DWS)数据库，在u1的同名SCHEMA u1下创建测试表u1.test，并插入数据。 12 CREATE TABLE test (id int, name varchar(50));INSERT INTO test VALUES (1, 'lily'); 打开一个新的连接会话Session B，使用系统管理员dbadmin连接GaussDB(DWS)数据库，开启事务1，执行UPDATE操作，UPDATE语句执行成功。 1234 START TRANSACTION;UPDATE u1.test SET id = 3 WHERE name = 'lily';UPDATE 1 在会话Session A中开启事务2，执行相同的UPDATE语句，执行报错。 1234 START TRANSACTION;UPDATE test SET id = 3 WHERE name = 'lily';ERROR: dn_6003_6004: abort transaction due to concurrent update test 289502. 针对上述案例，两个不同的事务并发更新了同一条记录，而并发更新同一条记录发生冲突不会等待锁，直接报错：abort transaction due to concurrent update。 在实际业务中，并不是只有并发UPDATE同一条记录会报错，select、delete等其他SQL并发操作，也有可能报错：abort transaction due to concurrent update。

排查方法 查看相关表CU中数据分布情况，以下操作在DN执行。 查看列存表对应的cudesc表 针对非分区表： 1 SELECT 'cstore.'||relname FROM pg_class where oid = (SELECT relcudescrelid FROM pg_class c inner join pg_namespace n on c.relnamespace = n.oid where relname = 'table name' and nspname = 'schema name'); 针对分区表： 1 SELECT 'cstore.'||relname FROM pg_class where oid in (SELECT p.relcudescrelid FROM pg_partition p,pg_class c,pg_namespace n where c.relnamespace = n.oid and p.parentid = c.oid and c.relname = 'table name' and n.nspname = 'schema name' and p.relcudescrelid != 0); 查看cudesc中各CU的rowcount情况 查询步骤一返回的cudesc表信息，查询结果类似如下，主要关注row_count过小（远小于6w）的CU数量，如果此数量较大，说明当前小CU多，CU膨胀问题严重，影响存储效率和查询访问效率。

分析过程 GUC参数comm_max_stream表示任意两个DN之间stream的最大数量。 在CN上查询当前任意两个DN之间stream情况： 1 SELECT node_name,remote_name,count(*) FROM pgxc_comm_send_stream group by 1,2 order by 3 desc limit 100; 在DN上查询当前DN与其他DN之间stream情况： 1 SELECT node_name,remote_name,count(*) FROM pg_comm_send_stream group by 1,2 order by 3 desc limit 100; comm_max_stream参数值必须大于并发数*每并发平均stream算子数*（smp的平方）。 该参数默认值为：通过公式min(query_dop_limit * query_dop_limit * 2 * 20, max_process_memory(字节) * 0.025 /(最大CN数+当前DN数) / 260)计算，小于1024按照1024取值，其中query_dop_limit = 单个机器CPU核数 / 单个机器DN数。 不建议该参数值设置过大，因为comm_max_stream会占用内存（占用内存=256byte*comm_max_stream*comm_max_datanode），如果并发数据流数过大，查询较为复杂及smp过大都会导致内存不足。 如果comm_max_datanode参数值较小，进程内存充足，可以适当将comm_max_stream值调大。

处理方法 故障构造场景 使用客户端连接DWS数据库。 执行以下SQL语句。 1 2 3 4 5 6 7 8 9101112 CREATE TABLE t1(a int, b timestamp);CREATE TABLECREATE TABLE t2(a int, b text);CREATE TABLEINSERT INTO t1 select 1, current_date;INSERT 0 1INSERT INTO t2 select 1, current_date;INSERT 0 1SELECT * FROM t1 UNION SELECT * FROM t2;ERROR: UNION types timestamp without time zone and text cannot be matchedLINE 1: SELECT * FROM t1 UNION SELECT * FROM t2; ^ 解决办法 示例中，t1表和t2表在b列上类型不同，导致在UNION操作时出现类型不匹配的报错，应保证UNION各分支相同位置的输出列类型匹配。 t2表b列是text类型，插入的数据是current_date，在插入时发生了隐式类型转换，所以插入不报错；但是在查询时，不会自动进行隐式转换，因此会报错。 解决以上问题，需保证UNION各分支的输出列类型匹配，不满足要求时可以对输出列强制类型转化。 123456 SELECT a,b::text FROM t1 UNION SELECT a,b FROM t2; a | b ---+--------------------- 1 | 2023-02-16 1 | 2023-02-16 00:00:00(2 rows)

处理方法 8.0以下版本集群清理系统表需要先执行DELETE FROM，再执行VACUUM FULL。 此处仅以gs_wlm_session_info系统表为例： 12 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。

原因分析 请先判断同名的表是否确实是同一张表。在关系型数据库中，确定一张表通常需要3个因素：database，schema，table。从问题现象描述看，database，table已经确定，分别是human_resource、areas。接着，需要检查schema。使用dbadmin，user01分别登录发现，search_path依次是public和"$user"。dbadmin作为集群管理员，默认不会创建dbadmin同名的schema，即不指定schema的情况下所有表都会建在public下。而对于普通用户如user01，则会在创建用户时，默认创建同名的schema，即不指定schema时表都会创建在user01的schema下。最终确定该案例发生时，确实因为2个用户之间交错对表进行操作，导致了同名不同表的情况。

处理方法 可使用ALTER USER或者ALTER ROLE语法指定USEFT参数赋予角色或用户使用外表的权限。 参数USEFT | NOUSEFT决定一个新角色或用户是否能操作外表，包括：新建外表、删除外表、修改外表、读写外表。 指定USEFT表示角色或用户可操作外表。 缺省为NOUSEFT。表示新角色或用户没有操作外表的权限。 请使用数据库管理员用户给普通用户或角色赋予使用外表的权限，示例如下： 1 ALTER USER user_name USEFT; 修改用户或角色权限等信息的详细内容请参见ALTER USER或者ALTER ROLE。 对普通用户或角色赋予使用外表的权限后即可创建外表。

问题现象 创建GDS或OBS外表语句时，管理员用户可以执行成功，但普通用户执行时报错“ERROR: permission denied to create foreign table in security mode.”。 1 2 3 4 5 6 7 8 91011121314151617181920 CREATE USER u1 PASSWORD '{password}';SET current_schema = u;CREATE FOREIGN TABLE customer_ft( c_customer_sk integer , c_customer_id char(16) , c_current_cdemo_sk integer , c_current_hdemo_sk integer , c_current_addr_sk integer ) SERVER gsmpp_server OPTIONS( location 'gsfs://192.168.0.90:5000/customer1*.dat', FORMAT 'TEXT' , DELIMITER '|', encoding 'utf8', mode 'Normal')READ ONLY;ERROR: permission denied to create foreign table in security mode

原因分析 系统连接数量超过了最大连接数量，会显示如下错误信息。 12 gsql -d human_resource -h 10.168.0.74 -U user1 -p 8000 -W password -rgsql: FATAL: sorry, too many clients already 用户不具备访问该数据库的权限，会显示如下错误信息。 123 gsql -d human_resource -h 10.168.0.74 -U user1 -p 8000 -W password -rgsql: FATAL: permission denied for database "human_resource"DETAIL: User does not have CONNECT privilege. 网络连接故障。

处理方法 通过toast的OID（示例中为2619，来源于报错信息的pg_toast_2619）查询出哪张表发生了损坏： 12345 SELECT 2619::regclass; regclass-------------- pg_statistic(1 row) 对已定位的损坏表（步骤1中查询得到的表pg_statistic），执行REINDEX和VACUUM ANALYZE操作。显示REINDEX/VACUUM，表示修复完成。如果修复过程中出现报错，请继续执行步骤3。 123 REINDEX table pg_toast.pg_toast_2619;REINDEX table pg_statistic;VACUUM ANALYZE pg_statistic; 执行以下的命令定位该表中损坏的数据行。 1 2 3 4 5 6 7 8 91011121314 DO $$declare v_rec record;BEGINfor v_rec in SELECT * FROM pg_statistic loop raise notice 'Parameter is: %', v_rec.ctid;raise notice 'Parameter is: %', v_rec;end loop; END;$$LANGUAGE plpgsql;NOTICE: 00000: Parameter is: (46,9)ERROR: XX000: missing chunk number 0 for toast value 30982 in pg_toast_2619CONTEXT: PL/pgSQL function inline_code_block line 7 at RAISE 将步骤3中定位的损坏数据行记录删除。 1 DELETE FROM pg_statistic WHERE ctid ='(46,9)'; 重复执行步骤3、步骤4，直到全部有问题的数据记录被删除。 损坏的数据行被删除后，执行步骤2中的REINDEX和VACUUM ANALYZE操作对该表重新进行修复。

问题现象 向表中插入数据报错：null value in column '%s' violates not-null constraint，此处s%指报错的列（字段）名。 1234 CREATE TABLE t1(a int, b int not null);INSERT INTO t1 VALUES (1);ERROR: dn_6001_6002: null value in column "b" violates not-null constraint

解决方案 针对上述案例，有两种解决方案： 方案一：使用ALTER TABLE删除字段b的非空（not null）约束 12345 ALTER TABLE t1 ALTER COLUMN b DROP NOT NULL;ALTER TABLEINSERT INTO t1 VALUES (1);INSERT 0 1 方案二：保持字段b的非空（not null）约束，字段b不再插入空值 在实际业务中，可根据实际情况选择解决方案。

JDBC DEV环境没问题，测试环境连接出错报空指针或URI报错uri is not hierarchical 问题分析：某些虚拟环境不支持获取扩展参数，需关闭。 处理方法：在连接时可设置连接参数“connectionExtraInfo=false”，详情可参见使用JDBC连接数据库。 1 jdbc:postgresql://host:port/database?connectionExtraInfo=false