[18][base_exception] FIX: undetected deadlock on installation with demo data - #3723
Open
florian-dacosta wants to merge 1 commit into
Open
[18][base_exception] FIX: undetected deadlock on installation with demo data#3723florian-dacosta wants to merge 1 commit into
florian-dacosta wants to merge 1 commit into
Conversation
detect_exceptions() stores the exceptions in a separate transaction (a new cursor/connection) so that they are kept when the ongoing transaction is rolled back. When the registry is not ready yet (module installation or update), the ongoing transaction holds exclusive locks on the tables it has just modified (ALTER TABLE ...). The call to _must_raise_exception_after_detection() made inside that new transaction then reads the model records, and the query waits for those locks forever: the only thread able to release them is the one waiting for them. This happens as soon as demo data confirming a sale order is loaded during a database initialisation with sale_exception installed (e.g. the sale_stock demo data), making the whole database initialisation hang. Use the current cursor in that case, as already done when running tests.
Contributor
|
Hi @hparfr, @sebastienbeau, |
rvalyi
approved these changes
Sep 10, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What happen is that during the installation or update of a module, the
init_modelsset a hard lock (ACCESS EXCLUSIVE) on the tables. And during this same transaction, the demo data is loaded, which may callaction_confirmon a sale order, which open a new cursor which will try a Select on the sale_order table... which is locked. So we kind of got a deadlock, but postgre won't detect it because the first lock (ACCESS EXCLUSIVE) is not waiting on the second lockNote: Odoo already protects the installation session itself with SET SESSION lock_timeout = '15s' (odoo/modules/loading.py), but the second connection does not inherit it, which is why the hang is not turned into an error after 15 seconds.
To reproduce the issue :
create a new database this way, WITH demo data : odoo -i sale_stock,sale_exception
Odoo will hang for ever during the loading of sale_stock demo data which confirm a sale order.
I guess a similar problem could happen in because of https://github.com/OCA/sale-workflow/blob/18.0/sale_exception/models/sale_order_line.py#L63
But let's wait a fix on this one before doing it in sale_exception (and maybe purchase_exception, I did not check but probably the same).
@simahawk @grindtildeath @rousseldenis
FYI @hparfr