Re: Update command causing lock in DB.

From: Gambhir Singh <gambhir(dot)singh05(at)gmail(dot)com>
To: Ron Johnson <ronljohnsonjr(at)gmail(dot)com>
Cc: Pgsql-admin <pgsql-admin(at)lists(dot)postgresql(dot)org>
Subject: Re: Update command causing lock in DB.
Date: 2025-05-08 09:32:35
Message-ID: CAHOGQfXSJEMLXA_jMySNHm0KP06nGkAfuL2nhqDrj1Wde95g5g@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-admin

They are using explicit transaction block and also got he root cause. They
to provide the commit explicitly.

Thanks & Regards
Gambhir Singh

On Wed, 7 May 2025 at 19:01, Ron Johnson <ronljohnsonjr(at)gmail(dot)com> wrote:

> On Wed, May 7, 2025 at 7:16 AM Gambhir Singh <gambhir(dot)singh05(at)gmail(dot)com>
> 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!
>

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Deividas Meskauskas 2025-05-12 00:58:56 adfaf
Previous Message Ron Johnson 2025-05-07 13:31:10 Re: Update command causing lock in DB.