Odoo Changelog — 2025-04-15

Tuesday, April 15, 2025

2 changes · saas-18.2

Improvements(2)

Enhancements to existing features

[IMP] base: reduce number of savepoint during partner merge

PR #205410

Coresaas-18.2baseMedium

Partner merge operations now avoid unnecessary database checkpoints when there is nothing to update or when extra safeguards are not needed. This should improve performance and reduce slowdowns during large merge operations without changing the business workflow.

Original PR description

When number of active savepoint grows over 64 it can greatly degrade the database performance, this commit tries to greatly reduce number of savepoint created during partner merge by:

- skipping UPDATE if there is no record
- doing the UPDATE without a savepoint() in case there is no CHECK nor UNIQUE constraint for that column on the table

task-4723964


---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#performance#partner-merge#database

[PERF] iap_extract: remove savepoint when uploading to the OCR server

PR #83248

Enterprisesaas-18.2iap_extractMedium

OCR document uploads were adjusted to avoid a database pattern that could slow down processing when many documents are uploaded. This improves performance, with a small trade-off that rare concurrent update errors may roll back the transaction and potentially consume OCR credits.

Original PR description

As this savepoint was initiated in a loop, it could lead to many subtransactions (one savepoint per document to upload) being active at the same time, causing performance issues (more info at [1]).

The main goal of that savepoint was to be able to recover from a SQL serialization failure that could occur when the document to upload was modified concurrently.

This was mostly useful in version 16.0 where the upload of the documents to the OCR server was performed asynchronously through a cron. This greatly increased the likelihood of serialization errors.

In version 17.0, we went back to synchronous uploads (commit 9df91d8), these should be much less frequent.
Considering this, it seems reasonable to remove the savepoint, although it implies that if such error occurs, the SQL transaction will be rollbacked and some OCR credits might be lost in the process.

[1]: https://www.postgresql.org/docs/current/subxacts.html, in particular the last sentence:
> The more subtransactions each transaction keeps open (not rolled back
> or released), the greater the transaction management overhead. Up to
> 64 open subxids are cached in shared memory for each backend; after
> that point, the storage I/O overhead increases significantly due to
> additional lookups of subxid entries in pg_subtrans.

When number of active savepoint grows over 64 it can greatly degrade the database performance, this commit tries to greatly reduce number of savepoint created during partner merge by: - skipping UPDATE if there is no record - doing the UPDATE without a savepoint() in case there is no CHECK nor UNIQUE constraint for that column on the table task-4723964 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

As this savepoint was initiated in a loop, it could lead to many subtransactions (one savepoint per document to upload) being active at the same time, causing performance issues (more info at [1]). The main goal of that savepoint was to be able to recover from a SQL serialization failure that could occur when the document to upload was modified concurrently. This was mostly useful in version 16.0 where the upload of the documents to the OCR server was performed asynchronously through a cron. This greatly increased the likelihood of serialization errors. In version 17.0, we went back to synchronous uploads (commit 9df91d8), these should be much less frequent. Considering this, it seems reasonable to remove the savepoint, although it implies that if such error occurs, the SQL transaction will be rollbacked and some OCR credits might be lost in the process. [1]: https://www.postgresql.org/docs/current/subxacts.html, in particular the last sentence: > The more subtransactions each transaction keeps open (not rolled back > or released), the greater the transaction management overhead. Up to > 64 open subxids are cached in shared memory for each backend; after > that point, the storage I/O overhead increases significantly due to > additional lookups of subxid entries in pg_subtrans.