Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uCckp-00HaLp-0g for pgsql-admin@arkaria.postgresql.org; Wed, 07 May 2025 11:15:59 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1uCcko-00DiXK-27 for pgsql-admin@arkaria.postgresql.org; Wed, 07 May 2025 11:15:58 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uCckn-00DiXB-NM for pgsql-admin@lists.postgresql.org; Wed, 07 May 2025 11:15:57 +0000 Received: from mail-ed1-x52e.google.com ([2a00:1450:4864:20::52e]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uCckl-000Zzq-0z for pgsql-admin@lists.postgresql.org; Wed, 07 May 2025 11:15:56 +0000 Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-5f6214f189bso12689135a12.2 for ; Wed, 07 May 2025 04:15:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1746616554; x=1747221354; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=+uVbIrtnIrVlok88dOU+Wu77v17hxhQYxEBEVvG/OdM=; b=Ryf9l4/dVfTqb/bPMXWyOORd+fignc/eb5KhZm8rzfsKruvpDiD9cAStWfownWDBUm 8uTaWpxlMAzdK+RPUWMWBgVVzKDl0bVhGfCECnityK9Efi/0b0Hgi2T841ljqhOkOueH 4w4lZq+LPIHYDF+y4yqXPmIRYJqdrSFtQqDlu5jQM8KMOQXUmuvxIxw1uY04NKWIbn0R 7TzwtSPb3StHQum8Os8vvRSdfVBLszzjfHH/m0zRyrYe9yrOCONy8yyyIMn79UXvfjpV keOcteiak7hZrI6jEp3Ql6V+t7/y7/LFgFJhfa9F+d0oBAhrmvdNj809pXLh7i1gnUdI GAig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746616554; x=1747221354; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=+uVbIrtnIrVlok88dOU+Wu77v17hxhQYxEBEVvG/OdM=; b=mdjtJB3twpqHQ8z5Ej4AIJgEyGyjQKTXVQF0HK+PhKsZ04Bjl93W1UxBppu1S8eIxd KUSws6yDtxSodiXdbA1/yuXlYJ50ubSUeYEisFQ+psrEyfV1WkFCjqp2q3MTGjjVaKGw jbvQ6BcPxg2uU1M+ClxAVNi1xTYJ+1HiJ8FNL6KjqEoppbr6u2tqi/nw2n/9x0EGnWhg XMKToDavcrg+ge2pN7/RamIQO0scSmQEMQWBm/eg91wEK7XN0qmELslOHRKGY31tr3KT UhPnK80jUwqjxI+QppObFxjvMkhplNuDs1JoqBQQ3jReN+z5hvQgKwwNsKHt/ywibam6 oCJg== X-Gm-Message-State: AOJu0Yy6zUGt4Hiiw60xznRmaV/yxTLm6d/nLDo7GOsZ6C4xUD9a63k0 9gos72aDjSqq7wSFy20qR7x1GbstmEUTvUEF6QQNUQxVmPxBkwHHoQOEkGN9lzhFNryZh3hUN8M YhTnXVAUBcyfaKXqJ+saqIzP2MTlg+/rZ X-Gm-Gg: ASbGnctKbU3rOSNjuQ/FGdUfUtklvZ93UrqRfFTkTdPOz9zvjAltwkp4y6xSa0tYhe2 SSj08fVp8niRTUL+t4KXnyiorc5g83QMRDMhWdQIyZS5EtaDI32t6gejHVoU6jJhQbND6EPPn22 FNl9AjaZnVtzCbZQyTAg7QvcXI4ycj0NJt6Uo2Bpi6xU7T2ndt/itLQitmUMI5jRvoow== X-Google-Smtp-Source: AGHT+IFY0uyyJBSvH4emUZ95JaNijkr6yJwUvdytQenAdh6QakjSutsDAktxAYgMpXULCRfZRiuPvC9cu9ChFhtEkfQ= X-Received: by 2002:a05:6402:2551:b0:5e5:e836:71f3 with SMTP id 4fb4d7f45d1cf-5fbe9fa8022mr2092512a12.29.1746616554191; Wed, 07 May 2025 04:15:54 -0700 (PDT) MIME-Version: 1.0 From: Gambhir Singh Date: Wed, 7 May 2025 16:45:17 +0530 X-Gm-Features: ATxdqUHWjIOUxD_cYcV8SZASCpmQ0ZxPYt4M9UvZV2c8CssGUiLoktERmP1OfaE Message-ID: Subject: Update command causing lock in DB. To: pgsql-admin@lists.postgresql.org Content-Type: multipart/alternative; boundary="00000000000045824f063489db48" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000045824f063489db48 Content-Type: text/plain; charset="UTF-8" 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. -- Thanks & Regards Gambhir Singh --00000000000045824f063489db48 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 spa= wned and executed the same UPDATE statement.

When I checked= the locks in DB, I found that both the sessions are updating the same reco= rd. 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. M= aybe I am wrong, please suggest how to handle this situation.

--
Thanks & Regards
Gambhir Singh

--00000000000045824f063489db48--