Here’s the relevant function in the Postgres source. If it already exists, our insertion will fail because we violated a unique constraint. Postgres simply looks up the tuple we’re attempting to insert in the unique index. In the case where only one transaction is writing to a unique index, the process is straightforward. It’s not uncommon to be in the worst case scenario described above, until, by sheer luck, insert ordering triggers the deadlock detector and cancels the transactions. The Postgres deadlock detector will detect the deadlock after deadlock_timeout (typically one second) 2 and cancel one of the transactions. If you were a bit luckier, you could have created deadlock within Postgres. In most cases you will leak database connections until your application hangs. The Postgres deadlock detector cannot save you. You now have an application level deadlock. A similar behavior can occur if application thread 1 is blocked for an unrelated reason eg. This seems far fetched, but I’ve seen it multiple times in practice in seemingly reasonable code.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |