Django code executed by post_save signal happens within atomic transaction

django, django-1.6, signals, transactions

Solution

Django's `get_or_create()` executes its `save()` in an atomic block, and signals fired post_save are nested within that atomic block.

My workaround was to override the native `get_or_create()` with my own version in a custom manager, without the `transaction.atomic()` block.

Problem

Upgrading to Django 1.6 has introduced a tricky problem into my code: database operations that are triggered by a `post_save` signal are getting contained within the `with transaction.atomic():` block of Django's `get_or_create()`. The impact for me is that custom sql (unmanaged) isn't getting committed to the db in time. Is there a different signal that I can use that gets sent after `obj.save()` exits its atomic block? Or have I diagnosed this wrong?

Original source