On 9/20/24 1:01 PM, veem v wrote:
>
> On Thu, 19 Sept, 2024, 8:40 pm Adrian Klaver, <adrian.klaver@aklaver.com
> <mailto:adrian.klaver@aklaver.com>> wrote:
>
> On 9/19/24 05:24, Greg Sabino Mullane wrote:
> > On Thu, Sep 19, 2024 at 5:17 AM veem v <veema0000@gmail.com
> <mailto:veema0000@gmail.com>
>
> > This is really difficult to diagnose from afar with only snippets of
> > logs and half-complete descriptions of your business logic. Pull
> > everyone involved into a room with a whiteboard, and produce a
> document
> > describing exactly what your application does, and how it is
> doing it.
> > Switch from reactive to proactive.
>
>
> Able to reproduce this deadlock graph as below. Now my question is ,
> this is a legitimate scenario in which the same ID can get inserted from
> multiple sessions and in such cases it's expected to skip that (thus "On
> conflict Do nothing" is used) row. But as we see it's breaking the code
Yeah, as I see it that would not work with concurrent uncommitted
sessions as it would be unresolved whether a conflict actually exists
until at least one of the sessions completes.
> with deadlock error during race conditions where a lot of parallel
> threads are operating. So how should we handle this scenario? Will
> setting the "lock_timeout" parameter at session level will help us
> anyway here?
Serializable transaction?:
https://www.postgresql.org/docs/current/transaction-iso.html#XACT-SERIALIZABLE
Or change the application code to not have this:
"... legitimate scenario in which the same ID can get inserted from
multiple sessions ..."
--
Adrian Klaver
adrian.klaver@aklaver.com
