西安手机网站定制网站建设,建设工程网站贴吧,工程施工公司,嵌入式培训机构排名前十1.问题
今天在上班途中#xff0c;中心的妹纸突然找我#xff0c;非常温柔的找我帮忙看个数据库的报错。当然以我的性格#xff0c;妹子找我的事情对我来说优先级肯定是最高的#xff0c;所以立马放下手中的“小事”#xff0c;转身向妹子走去。具体是一个什么样的问题呢…1.问题
今天在上班途中中心的妹纸突然找我非常温柔的找我帮忙看个数据库的报错。当然以我的性格妹子找我的事情对我来说优先级肯定是最高的所以立马放下手中的“小事”转身向妹子走去。具体是一个什么样的问题呢
可以看到这是一个postgreSQL的问题妹子通过python的pscopg2包通过executemany()的方法对PostgreSQL数据库进行多条数据的写入操作但是报了以下错误
psycopg2.errors.InFailedSqlTransaction: current transaction is aborted, commands ignored until end of transaction block 2.问题分析
对这个问题乍看一眼其实就是当前的事务被中断了但是具体什么原因这里并没有告诉我们所以第一想法这会不会是触发了什么bug导致事务突发中断。但是为了解决妹子多条数据插入这个事情我们还是得确定它问题到底是不是bug。于是我们还是得先到数据库上看看这个事务的相关日志。
通过对日志的检查我们看到了以下操作过程
2023-11-15 15:29:53.682 CST [52096] STATEMENT: data [(202311,cpu,18%,,),(202311,men,50%,test,),(202311,storage,3%,,)]sql insert into aa (a,b,c,d) value (%s,%s,%s,%s)select * from fk ;
2023-11-15 15:33:52.180 CST [54538] ERROR: syntax error at or near value at character 40
2023-11-15 15:33:52.180 CST [54538] STATEMENT: insert into aa (a,b,c,d) value (202311,cpu,18%,)
2023-11-15 15:34:06.611 CST [54538] ERROR: current transaction is aborted, commands ignored until end of transaction block从数据库层查看可以看出程序通过data定义一个列表列表中包含了三组数据并通过insert的sql插入数据库但是当我们执行到第一个sql时由于语法错误(insert into … values …的values写成了value)导致插入语句失败然后报出了我们看到的事务中断的错误。 嗨看到这里松了口气其实就是语法写错导致事务中断而已不是什么bug嘛既然事务失败了那么我们重新发起操作即可。可是妹子又跟我说后续她改正了错误然后执行可还是会报这个错误。
这时我突然想起在很久之前做过的一些关于pg事务的测试当时突然测试出一个奇怪的现象就是当我手动启用一个事务的时候如果这个事务中的sql执行出错那么我接着改正sql继续执行还是会报错只有当我做了rollback或者commit之后才能够在这个会话中继续执行sql。
而妹子遇见的这个现象好像和这个确实很像为了进一步验证想法我做了之前的实验过程很简单
begin;
BEGIN
insert into fk value(now(),1,2,3);
ERROR: syntax error at or near value
LINE 1: insert into fk value(now(),1,2,3);^
insert into fk values(now(),1,2,3);
ERROR: current transaction is aborted, commands ignored until end of transaction block
insert into fk values(now(),3,2,3);
ERROR: current transaction is aborted, commands ignored until end of transaction block
insert into fk values(now(),3,2,);
ERROR: current transaction is aborted, commands ignored until end of transaction block
select * from fk;
ERROR: current transaction is aborted, commands ignored until end of transaction block很容易的我们模拟出了这个问题这个时候我们去看当前的活动会话postgres# select pid,usename,application_name,wait_event_type,wait_event,state,query from pg_stat_activity where wait_event_typeClient;pid | usename | application_name | wait_event_type | wait_event | state | query
------------------------------------------------------------------------------------------------------------------19137 | postgres | psql | Client | ClientRead | idle in transaction (aborted) | select * from aa;
(1 row)此时我们通过rollback结束这个事务rollback;
ROLLBACK再次查看当前活动会话postgres# select pid,usename,application_name,wait_event_type,wait_event,state,query from pg_stat_activity where wait_event_typeClient;pid | usename | application_name | wait_event_type | wait_event | state | query
----------------------------------------------------------------------------------19137 | postgres | psql | Client | ClientRead | idle | rollback;--插入数据测试
insert into aa values(now(),1,2,3);
INSERT 0 1--查询表测试
select * from aa;
...注我们知道在postgresql中通过psql登陆事务默认是自动提交的因此我们不需要在dml操作后执行commit或者rollback操作想要关闭事务的自动提交则有两个方法
1.通过begin指定开始一个事务块
2.通过设置AUTOCOMMIT的方式关闭自动提交postgres# \set AUTOCOMMIT off
postgres# \echo :AUTOCOMMIT
off那么上面的现象就很好理解了我通过begin的方式开启了一个事务块在这个事务块中我执行了一个错误的sql导致这个事务出现问题中断而这个事务则进入了一个“中间态”而会话则是一个idle in transaction (aborted)的状态此时只要在这个会话中不论我们执行什么sql都会报错。而当我做了rollback后则结束了这个事务同时会话也成为了idle状态。而我们再次做其他操作时则是进入了新的事务并自动提交。
那么妹子的事情也能解释的通了通过python等客户端对数据库进行连接操作默认是开启了一个事务块。妹子在写测试sql的时候发现了错误并及时修正但是并未做回滚或提交结束事务。此时事务处于“中间态”会话处于abort。
3.源码证实
虽然妹子的问题解决了但是实际是不是这样呢这只能在源码中看看了。在源码中我找到这么一段代码及描述
大概意思就是说当我们在一个事务块中由于语句造成的中断虽然我们什么都没做成但是它还会保持中断状态直到我们收到一个rollback命令而当我们从用户客户端收到了rollback命令那么我们就会讲已经abort的回话清理并恢复到空闲状态。
4.总结
从这个问题中我们可以看到PostgreSQL在进行事务操作时候为了保证事务的一致性会有一个事务的“中间态”这里我打个比方即这个“中间态”保证了PostgreSQL同一个事务中的操作“一荣俱荣一损俱损”。即在一个事务中我们可能会存在多个dml操作而当其中的一个操作失败后整个事务中的操作都会失败并且需要手动回滚而不会存在部分成功部分失败。
对比oracle/mysql当我们在一个事务中执行多个dml操作时正确的操作则会成功(这里会写入到buffer中旧数据则会在undo中)错误的操作则会失败从而形成了部分成功的情况。
这样看来好像PostgreSQL的事务对于整个业务的一致性要更加严谨。比如A给B转钱那么A的账户要减掉10000B的账户要增加10000。我们可以将这个过程分为两个update操作如果按照Oracle/Mysql数据库层面的处理逻辑但当某些原因B账户增加10000的update执行失败此时如果我们做了commit操作那么则只有A的账户被被更新B的账户则不变此时业务则出现了错误。但是如果以PostgreSQL的“中间态”理解此时A、B的账户则都会回退看起来更加合理。
当然这只是我的一些理解也欢迎各位大佬可以一起交流指正错误。
