Re: IO related waits

On 9/20/24 1:01 PM, veem v wrote:
>
> On Thu, 19 Sept, 2024, 8:40 pm Adrian Klaver, <adrian(dot)klaver(at)aklaver(dot)com
> <mailto:adrian(dot)klaver(at)aklaver(dot)com>> wrote:
>
> On 9/19/24 05:24, Greg Sabino Mullane wrote:
> > On Thu, Sep 19, 2024 at 5:17 AM veem v <veema0000(at)gmail(dot)com
> <mailto:veema0000(at)gmail(dot)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(dot)klaver(at)aklaver(dot)com