Changes between Version 1 and Version 2 of Ticket #28676, comment 2


Ignore:
Timestamp:
Oct 4, 2017, 1:41:03 AM (7 years ago)
Author:
M1ha Shvn

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #28676, comment 2

    v1 v2  
    441) According to  [https://www.postgresql.org/docs/9.2/static/monitoring-stats.html PostgreSQL docs] state "idle in transaction" means that query was executed and control returned to backend code, but it hasn't committed the transaction yet. But save() is stuck somewhere (it is incorrect). If I place print(123) after it - it will not print anything. So PostgreSQL ended its work, but save() method stopped, waiting for something and not continuing code execution. The expected behavior of django here is to leave save() method, than leave "with transaction.atomic" context manager and commit transaction, so other transaction can go in. The proof is replacing save() method with QuerySet.update(). As you can see on the screen, it generates perfectly the same SQL, but works fine without stucking.
    552) The second strange factor is duplicate select query, generated inside save() method. As you can see from above and screen, it's the same query without "FOR UPDATE". But there is no need in this query - conversation data has been already selected by "SELECT ... FOR UPDATE". According to [https://docs.djangoproject.com/en/1.10/ref/models/instances/#what-happens-when-you-save the docs], save() should do only one query - INSERT or UPDATE (UPDATE in this situation) without any SELECT queries.
    6 P. s. The only reason for save of doing second SELECT from the docs is getting pk value. But it is not INSERT query, pk is already defined. Moreover force_update=True doesn't change anything.
     6P. s. The only reason for save() of doing second SELECT from the docs is getting pk value. But it is not INSERT query, pk is already defined. Moreover force_update=True doesn't change anything.
    77
    88Replying to [comment:1 Tim Graham]:
Back to Top