Exactly, that’s why there’s a limit on the retry number. On the last try I wanted something like full lockdown to make sure the transaction will not fail due to serialiazation failure (if no other processes are touching the database, it can’t happen).
So if two transactions were retrying over and over, the first one to reach max_retries would activate that “global lock” making the other one wait and then the second one would also be able to successfully commit... > On 11/06/2015, at 20:27, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Filipe Pina <filipe.p...@impactzero.pt> writes: >> It will try 5 times to execute each instruction (in case of >> OperationError) and in the last one it will raise the last error it >> received, aborting. > >> Now my problem is that aborting for the last try (on a restartable >> error - OperationalError code 40001) is not an option... It simply >> needs to get through, locking whatever other processes and queries it >> needs. > > I think you need to reconsider your objectives. What if two or more > transactions are repeatedly failing and retrying, perhaps because they > conflict? They can't all forcibly win. > > regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
