[midPoint] [Newsletter] Re: Postgresql errors. Normal?

Chris Woods Chris.Woods at rohde-schwarz.com
Thu May 20 16:24:28 CEST 2021


Hi Pavol,
ok, thanks very much. They do appear quite often and I'm still trying to find out why I get a situation where the java process is still running, but no communication to/from midpoint is possible :(.
I will let you know what I find.
Regards,
Chris

From: midPoint <midpoint-bounces at lists.evolveum.com> On Behalf Of Pavol Mederly via midPoint
Sent: Thursday, May 20, 2021 4:13 PM
To: midpoint at lists.evolveum.com
Cc: Pavol Mederly <mederly at evolveum.com>
Subject: *EXT* [Newsletter] Re: [midPoint] Postgresql errors. Normal?


Hello Chris,

in general, these errors are benign. They are part of standard midPoint approach to serializing access to the repository.

They should become a concern only if there are too many of them. This can be observed by looking at task's Internal performance tab (local tab performance), or Internals configuration -> Performance tab (global, node-wide performance counters). There is something like this (exact formatting depends on midPoint version):

[cid:image001.png at 01D74D94.975297F0]

And, in the new PostgreSQL-based repo (in 4.4) we assume we will loose the DB transaction isolation level, so there should be less of these retries. Most probably. :)

Best regards,

--

Pavol Mederly

Software developer

evolveum.com
On 20/05/2021 15:44, Chris Woods via midPoint wrote:
Hi all,
just wondering if anyone else has come across these error messages in their postgres logs:



2021-05-20 13:39:10.901 UTC [1537] ERROR:  could not serialize access due to concurrent update



2021-05-20 13:39:10.901 UTC [1537] STATEMENT:  update m_object set createChannel=$1, createTimestamp=$2, creatorRef_relation=$3, creatorRef_targetOid=$4, creatorRef_targetType=$5, fullObject=$6, lifecycleState=$7, modifierRef_relation=$8, modifierRef_targetOid=$9, modifierRef_targetType=$10, modifyChannel=$11, modifyTimestamp=$12, name_norm=$13, name_orig=$14, objectTypeClass=$15, tenantRef_relation=$16, tenantRef_targetOid=$17, tenantRef_targetType=$18, version=$19 where oid=$20



2021-05-20 13:40:19.775 UTC [1605] ERROR:  could not serialize access due to concurrent update



2021-05-20 13:40:19.775 UTC [1605] STATEMENT:  update m_object set createChannel=$1, createTimestamp=$2, creatorRef_relation=$3, creatorRef_targetOid=$4, creatorRef_targetType=$5, fullObject=$6, lifecycleState=$7, modifierRef_relation=$8, modifierRef_targetOid=$9, modifierRef_targetType=$10, modifyChannel=$11, modifyTimestamp=$12, name_norm=$13, name_orig=$14, objectTypeClass=$15, tenantRef_relation=$16, tenantRef_targetOid=$17, tenantRef_targetType=$18, version=$19 where oid=$20



2021-05-20 13:41:26.803 UTC [1673] ERROR:  could not serialize access due to concurrent update



2021-05-20 13:41:26.803 UTC [1673] STATEMENT:  update m_object set createChannel=$1, createTimestamp=$2, creatorRef_relation=$3, creatorRef_targetOid=$4, creatorRef_targetType=$5, fullObject=$6, lifecycleState=$7, modifierRef_relation=$8, modifierRef_targetOid=$9, modifierRef_targetType=$10, modifyChannel=$11, modifyTimestamp=$12, name_norm=$13, name_orig=$14, objectTypeClass=$15, tenantRef_relation=$16, tenantRef_targetOid=$17, tenantRef_targetType=$18, version=$19 where oid=$20



2021-05-20 13:41:26.870 UTC [1676] ERROR:  could not serialize access due to concurrent update



2021-05-20 13:41:26.870 UTC [1676] STATEMENT:  update m_object set createChannel=$1, createTimestamp=$2, creatorRef_relation=$3, creatorRef_targetOid=$4, creatorRef_targetType=$5, fullObject=$6, lifecycleState=$7, modifierRef_relation=$8, modifierRef_targetOid=$9, modifierRef_targetType=$10, modifyChannel=$11, modifyTimestamp=$12, name_norm=$13, name_orig=$14, objectTypeClass=$15, tenantRef_relation=$16, tenantRef_targetOid=$17, tenantRef_targetType=$18, version=$19 where oid=$20



2021-05-20 13:41:26.928 UTC [1676] ERROR:  could not serialize access due to concurrent update



2021-05-20 13:41:26.928 UTC [1676] STATEMENT:  update m_object set createChannel=$1, createTimestamp=$2, creatorRef_relation=$3, creatorRef_targetOid=$4, creatorRef_targetType=$5, fullObject=$6, lifecycleState=$7, modifierRef_relation=$8, modifierRef_targetOid=$9, modifierRef_targetType=$10, modifyChannel=$11, modifyTimestamp=$12, name_norm=$13, name_orig=$14, objectTypeClass=$15, tenantRef_relation=$16, tenantRef_targetOid=$17, tenantRef_targetType=$18, version=$19 where oid=$20

and whether they should be of concern or not :)

Thanks in advance,
Chris.

CHRIS WOODS
Identity Management
Information and Business Technology

Rohde & Schwarz GmbH & Co. KG
Mühldofstraße 15| 81671 München
Telefon: +49 89 4129 15735
Internet: https://www.rohde-schwarz.com<https://www.rohde-schwarz.com/>




_______________________________________________

midPoint mailing list

midPoint at lists.evolveum.com<mailto:midPoint at lists.evolveum.com>

https://lists.evolveum.com/mailman/listinfo/midpoint
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20210520/9c437ff5/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 55757 bytes
Desc: image001.png
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20210520/9c437ff5/attachment-0001.png>


More information about the midPoint mailing list