: 世界上功能最强大的开源数据库...

charming	RC事务隔离级别抛错could not serialize ... ... 2019-12-16 21:31:53+08...1楼
	我在odoo运行的库中发现了如下报错 < 2019-12-16 17:09:54.928 CST > STATEMENT: UPDATE ir_model SET info=' Main super-class for regular database-persisted Odoo models.` Odoo models are created by inheriting from this class:: class user(Model): ... The system will later instantiate the class once per database (on which the class'' module is installed). ',state='base',transient=false,is_mail_thread=true,name='费用继承修改' WHERE model='hr.expense' RETURNING id `< 2019-12-16 17:09:55.486 CST > ERROR: could not serialize access due to concurrent update` `< 2019-12-16 17:09:55.486 CST > STATEMENT: UPDATE ir_module_module SET state='installed' WHERE state IN ('to remove', 'to upgrade')` `< 2019-12-16 17:34:33.108 CST > ERROR: could not serialize access due to concurrent update` `< 2019-12-16 17:34:33.108 CST > STATEMENT: UPDATE ir_model SET is_mail_thread=true,info=' Update partner to add a field about notification preferences. Add a generic opt-out field that` `can be used` `to restrict usage of automatic email templates. ',transient=false,state='base',name='res继承修改' WHERE model='res.partner' RETURNING id` `< 2019-12-16 17:34:35.555 CST > ERROR: could not serialize access due to concurrent update` `< 2019-12-16 17:34:35.555 CST > STATEMENT: UPDATE "ir_ui_view" SET "write_uid"=1,"write_date"=(now() at time zone 'UTC') WHERE id IN (147)` `< 2019-12-16 17:34:38.681 CST > ERROR: could not serialize access due to concurrent update` `< 2019-12-16 17:34:38.681 CST > STATEMENT: UPDATE "res_lang" SET "active"=true,"write_uid"=1,"write_date"=(now() at time zone 'UTC') WHERE id IN (11)` `< 2019-12-16 17:34:42.410 CST > ERROR: could not serialize access due to concurrent update` `< 2019-12-16 17:34:42.410 CST > STATEMENT: UPDATE "res_lang" SET "active"=true,"write_uid"=1,"write_date"=(now() at time zone 'UTC') WHERE id IN (11)` `< 2019-12-16 17:34:42.928 CST > ERROR: could not serialize access due to concurrent update` `< 2019-12-16 17:34:42.928 CST > STATEMENT: UPDATE ir_module_module SET state='installed' WHERE state IN ('to remove', 'to upgrade')` `< 2019-12-16 17:42:36.540 CST > ERROR: could not obtain lock on row in relation "ir_cron"` `< 2019-12-16 17:42:36.540 CST > STATEMENT: SELECT *` `FROM ir_cron` `WHERE numbercall != 0` `AND active` `AND nextcall <= (now() at time zone 'UTC')` `AND id=2` `FOR UPDATE NOWAIT` `< 2019-12-16 17:42:38.693 CST > ERROR: could not serialize access due to concurrent update 查询了官方文档说明，在RR级别下才会产生这个问题，但是我设置的是transaction_isolation level 为RC读已提交 The Repeatable Read isolation level only sees data committed before the transaction began; it never sees either uncommitted data or changes committed during transaction execution by concurrent transactions. (However, the query does see the effects of previous updates executed within its own transaction, even though they are not yet committed.) This is a stronger guarantee than is required by the SQL standard for this isolation level, and prevents all of the phenomena described in Table 13.1 except for serialization anomalies. As mentioned above, this is specifically allowed by the standard, which only describes the minimum protections each isolation level must provide. This level is different from Read Committed in that a query in a repeatable read transaction sees a snapshot as of the start of the first non-transaction-control statement in the transaction, not as of the start of the current statement within the transaction. Thus, successive SELECT commands within a single transaction see the same data, i.e., they do not see changes made by other transactions that committed after their own transaction started. Applications using this level must be prepared to retry transactions due to serialization failures. UPDATE, DELETE, SELECT FOR UPDATE, and SELECT FOR SHARE commands behave the same as SELECT in terms of searching for target rows: they will only find target rows that were committed as of the transaction start time. However, such a target row might have already been updated (or deleted or locked) by another concurrent transaction by the time it is found. In this case, the repeatable read transaction will wait for the first updating transaction to commit or roll back (if it is still in progress). If the first updater rolls back, then its effects are negated and the repeatable read transaction can proceed with updating the originally found row. But if the first updater commits (and actually updated or deleted the row, not just locked it) then the repeatable read transaction will be rolled back with the message ERROR: could not serialize access due to concurrent update because a repeatable read transaction cannot modify or lock rows changed by other transactions after the repeatable read transaction began. 下面是我的配置 NNew=# show transaction_isolation; transaction_isolation ----------------------- read committed (1 row)
	我的签名：

您还没有登录,请您登录后再发表回复