From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | gerry gan <xiang(dot)gan(dot)aalto(at)gmail(dot)com> |
Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Is consistent (deterministic) ordering possible in our case? |
Date: | 2021-06-03 02:51:39 |
Message-ID: | 242820.1622688699@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
gerry gan <xiang(dot)gan(dot)aalto(at)gmail(dot)com> writes:
> Thanks for the comments! I have a naive question related to the use of
> advisory lock. Based on my current reasoning about our scenario, consistent
> ordering of commands in two transactions might not help to solve the
> deadlock situation. If advisory lock is used, it can return false in case
> it cannot get lock on certain row. This, however, might occur in both
> transactions. Then it seems to be hard to continue from application side
> since the operation is, by any means, required by application logic. In
> other words, I guess this might cause 'deadlock' in applications. Do you
> have any suggestions to solve this situation? And I'm sorry if my question
> is naive. Thank you!
A common answer to this sort of problem is to be willing to retry
transactions after deadlock failures. If the deadlocks are common,
maybe this won't be workable from a performance standpoint. But if
they're rare, or you can tweak things to make them so, think about it.
Retries can be a lot simpler, more robust, and even more performant
than trying to get to a provably-deadlock-free implementation.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | PG Bug reporting form | 2021-06-03 10:50:18 | BUG #17046: Upgrade postgres 11 to 13 version |
Previous Message | gerry gan | 2021-06-03 01:34:46 | Re: Is consistent (deterministic) ordering possible in our case? |