public inbox for [email protected]  

help / color / mirror / Atom feed

From: Ron Johnson <[email protected]>
To: Pgsql-admin <[email protected]>
Subject: Re: Update command causing lock in DB.
Date: Wed, 7 May 2025 09:31:10 -0400
Message-ID: <CANzqJaDP=Eg_9d6aN4C8oy-na-MJhXyP7zAqLJhekBqxs75eUA@mail.gmail.com> (raw)
In-Reply-To: <CAHOGQfWk-xb3q0QSXY=xUsMohChEEZwjxoTzrFUK+D_GEcO+uw@mail.gmail.com>
References: <CAHOGQfWk-xb3q0QSXY=xUsMohChEEZwjxoTzrFUK+D_GEcO+uw@mail.gmail.com>

On Wed, May 7, 2025 at 7:16 AM Gambhir Singh <[email protected]>
wrote:

> Hi,
>
> Application team was executing UPDATE statement in DB through Abinitio
> graph. When they trigger a job, a session is spawned in DB, in parallel
> another session is also spawned and executed the same UPDATE statement.
>
> When I checked the locks in DB, I found that both the sessions are
> updating the same record. My concern is how UPDATE causes locking in DB.
>
> Here is how MVCC works. If one session is updating a record, it should
> release the lock once it updated the row and other one should be able to
> acquire the row lock. Maybe I am wrong, please suggest how to handle this
> situation.
>

Do the applications use implicit autocommit, or do they use explicit
transaction blocks?

-- 
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!

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]
  Subject: Re: Update command causing lock in DB.
  In-Reply-To: <CANzqJaDP=Eg_9d6aN4C8oy-na-MJhXyP7zAqLJhekBqxs75eUA@mail.gmail.com>

* 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