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