老事务简单指拿着事务号执行时间长的语句，例如insert, delete,update等，按照实例来看两种情况都有可能：CN上执行时间长；DN线程残留。通常DN线程残留时间更长，影响范围更广

是的，这个需要根据实际存储过程分析exception的原因

release s1 , savepoint s1 是使用带Exception的存储过程时系统自动加入的。GaussDB带Exception的存储过程在实现上是基于子事务实现的，简单对应关系如下：       begin                     (Savepoint s1)            DDL/DML       exception                     (Rollback to s1)                     (Release s1)              …       end存储过程启动时如果有Exception则会启动一个子事务，如果出现Exception则会回滚当前事务并进行异常的处理；如果没有出现Exception则会直接提交前面的子事务。

last_vacuum默认值是NULL，如果没有脏数据，做完vacuum full analyze也不会更新该字段。可以做个简单的实验：create table t(a int);select last_vacuum from pg_stat_all_tables where relname='t'; last_vacuum-------------(1 row)insert into t values(generate_series(1,100));vacuum full analyze t;select last_vacuum from pg_stat_all_tables where relname='t';  last_vacuum-------------(1 row)delete from t;vacuum full analyze t;select last_vacuum from pg_stat_all_tables where relname='t';          last_vacuum------------------------------- 2021-01-30 20:14:39.806551+08

Gaussdb (DWS) 8.1

vacuum full在新版本上主表依旧拿最高级锁truncate在新版本上主表拿一级锁

pg_toast： 存放toast表信息，toast表是用来存储大字段数据，当表结构中含有text类型字段，就会自动建立一个对应的toast表；pg_catalog： 存放系统表信息，例如pg_class，pg_type，pg_attribute等；information_schema：存放定义在当前数据库中对象的信息，例如sql_features，sql_languages等;cstore：列存表的基本存储单元是CU，每个cu的描述信息存放在对应的cudesc表中，cudesc表存储在cstore模式下;pmk：GaussDB 提供了gs_checkperf工具来帮助对集群级别（主机CPU占用率、Gauss CPU占用率、I/O使用情况等）、节点级别（CPU使用情况、内存使用情况、I/O使用情况）、会话/进程级别（CPU使用情况、内存使用情况、I/O使用情况）、SSD性能（写入、读取性能）进行定期检查，让用户了解集群的负载情况，采取对应的改进措施。gs_checkperf工具的监控信息依赖于pmk模式下的表的数据;mppdbpermission: 存放FI Manager用户数据信息。

1. CN收到导入语句后，与GDS建连，解析语句并分发任务给DN。DN与GDS建连，开始任务导入。这个过程中CN需要从GTM获取事务号和快照，下发给DN。如果导入成功，参与实例上的CSN 自增1；导入失败则不变。2. GDS不会对数据进行hash ，GDS会将数据发送给各个DN， 由各个DN进行hash路由进行 redistribute。 （DN 做redistribute 因此会有网络开销） 。  如果是GDS hash 路由的话， 就不能充分利用到DN 的计算能力了。3. 目前DRS 回放的数据可以以微批的方式生成csv 文件，通过copy manager 接口加载到数据库。 copy manager 接口不能像gds一样实现DN 并行加载。至于为什么不用GDS对drs生成的数据做并行导入，是因为对于微批量(每次几千条数据)不见得GDS的并行加载速度比COPY 快。 GDS的主要场景用于大批量数据的加载，比如历史数据迁移。4. 不支持ETL等工具连接DN。

上次遇到一个create table as select的场景，入库数据量大，耗时长，需要打开这个开关才能找到这张表。不然查不到，当残留处理就危险了

从现象看，是并发建表导致的。复现过程：session Abegin；create table t(a int);session B：set lockwait_timeout='1s';set max_query_retry_times=0；begin；create table t(a int);此时session B报错如下：ERROR:  Lock wait timeout: thread 139780858820352 on node coordinator1 waiting for ShareLock on transaction 1010092 after 2000.083 msDETAIL:  blocked by hold lock thread 139781231081216, statement , hold lockmode ExclusiveLock.你的现象中持锁线程号为0，说明此时事务正在提交，锁冲突语句显示两阶段事务。建议从业务排查是否存在并发建同名表的情况