public inbox for [email protected]
help / color / mirror / Atom feedFrom: Adrian Klaver <[email protected]>
To: veem v <[email protected]>
Cc: Greg Sabino Mullane <[email protected]>
Cc: Christophe Pettus <[email protected]>
Cc: pgsql-general <[email protected]>
Subject: Re: IO related waits
Date: Fri, 20 Sep 2024 14:11:38 -0700
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAB+=1TXEJTMtypsZrNhGVEZxRV6jBop4hmMaR5DDsTLOoSqsdQ@mail.gmail.com>
References: <CAB+=1TWZNvMhVthJ2iKs_Q4qBzMw-v_oaSz7HbFE_P_qC5jMFA@mail.gmail.com>
<[email protected]>
<CAB+=1TWdRd2sBw7-vXCovH_VHLANh+aSaU-WyJ2m8tL4TkF=8g@mail.gmail.com>
<[email protected]>
<CAB+=1TV-b8=RGKVFN0qj5Nxdgbj-JYCNh4ZqFjxxmQPpFD6=PQ@mail.gmail.com>
<[email protected]>
<CAB+=1TXn-TZFC5QAFDshpRpnNhGrZ847sdaivNJRgot-6BuerA@mail.gmail.com>
<CAB+=1TWhGgybtCdU7oR3oghhXG6vULUEkebG1DbT+bc1v7yp4w@mail.gmail.com>
<[email protected]>
<CAB+=1TXcLJsZoGZ2qzv5ehauOa3GX_-cHth4NvZ2mgFsJPCffA@mail.gmail.com>
<CAKAnmmJhsNL=f+z7R018L6NrLQuq_7+quqZkGUKbzHRctHaY3w@mail.gmail.com>
<[email protected]>
<CAB+=1TXEJTMtypsZrNhGVEZxRV6jBop4hmMaR5DDsTLOoSqsdQ@mail.gmail.com>
On 9/20/24 1:01 PM, veem v wrote:
>
> On Thu, 19 Sept, 2024, 8:40 pm Adrian Klaver, <[email protected]
> <mailto:[email protected]>> wrote:
>
> On 9/19/24 05:24, Greg Sabino Mullane wrote:
> > On Thu, Sep 19, 2024 at 5:17 AM veem v <[email protected]
> <mailto:[email protected]>
>
> > 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
[email protected]
view thread (17+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: IO related waits
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox