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.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