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.96) (envelope-from ) id 1wQQnR-001YMm-05 for pgsql-admin@arkaria.postgresql.org; Fri, 22 May 2026 14:24:17 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wQQnN-00DHrU-2h for pgsql-admin@arkaria.postgresql.org; Fri, 22 May 2026 14:24:14 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wQQnN-00DHrL-1X for pgsql-admin@lists.postgresql.org; Fri, 22 May 2026 14:24:14 +0000 Received: from mail-lf1-x12b.google.com ([2a00:1450:4864:20::12b]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wQQnM-00000000tr7-02nA for pgsql-admin@lists.postgresql.org; Fri, 22 May 2026 14:24:13 +0000 Received: by mail-lf1-x12b.google.com with SMTP id 2adb3069b0e04-5a88db610ccso7731304e87.2 for ; Fri, 22 May 2026 07:24:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1779459846; cv=none; d=google.com; s=arc-20240605; b=O3t0yRCevdd8jLcZWo5+V2sdofnT97KDThao1nNm+LzHohN9RgwEmacqsTJFca5KpC HhWcds6GtJjfD5z6AzkNA3wwB56N8N9kTp+rkSggocxVR3AsXgsV3anAAnnkL6ohO0le pnU0qJD/g0ZCqgRrERP3atn45LTeGafH9JOeUi/KRhqIdqXsDDclPxMdGTmui5rjBDmh P2UomaOAuDNCmkSreUeI5Rtjx0zdp0PlXknpRZPn3yHx2YuWPxS2Q/xaU0LYE3DnXC/o W+bwV7RX/92ov4t8Glgz+3yDv7WYwSxSVGoXJt1G4kB4rIq2f03lneYU3ak4aXYnrV/b Cfcg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=Jt/DtlrzP2zfdusrkZSHutmLo/XcpxWZ+5qXQ5XHFg8=; fh=YVqAsyQLaqkSOJ1zvqJdlUnoB6bSkwHNHq4/MX0Vk/s=; b=H54rSz07hGrGz4hHGHvUs3n7UIvKpUpPofp2J7Fusjqq3uKum7e3qwHBoh62DspgRT Sj6k3Efp+dvpxLlItawURuf2QJXNu7J3YnusUDwU5mStT1PNjWCDcIGZWJGUvK5t3Qc6 03fnW2xGfRcZwXHBwdtaJYFxARrm+D54mjF0FE9EW2FdJzyD6oqwUiEowqei53nVukyw 5b8Z/O1cDtBdrja/62pO4u6MDcnUoGKoUVD8R9zyNbZobQ0XAgmnyIa5Ts84g/BV6X6E SXhM28FyBoKkxBxBbQW9jMqHciphQJYjhqhapoJuu57hJYQCN9zUMqOPbt9JFilt/sXk ou2w==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779459846; x=1780064646; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Jt/DtlrzP2zfdusrkZSHutmLo/XcpxWZ+5qXQ5XHFg8=; b=V1uyidLs7DTcAiKR560RQXv56eS27yox1ujxHsPEKA8pkOZw+HFcyTVhLAPrfeMpD7 V+jbLKOHZpfLgERYtHE593a2k/IAMxg0/2vmtRyLBQYqE8xrPnk/J1RfAY3IjDUF2rVY TBCDHSxgwnG245BUkuWzHpQlcOopWBz7EOQVZ7r7OOSeI1PLRKPFQDjnUvgqJE9F+nhy fYNWJuBiypnOvDLR8KxZuidi7I9u5hZFFjBaSwhV4ijwvgRTNVdbvErMOeYRKtnJh+d2 zbm/SPijFCjLoR8KNywOQYtTkoXI5ItEuifRlFmmf0/JXsui6oEHMoa7mG4lPufRxc63 RZ7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779459846; x=1780064646; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Jt/DtlrzP2zfdusrkZSHutmLo/XcpxWZ+5qXQ5XHFg8=; b=jSrim667P6hNjkksK7Kiy0f/sllecoOQ/O8KQW4nTV6DpNCQMG5A63u6+YfgxjRqCp vc9DNfJIp1kvGmrjiFKmna1UHImotKoshamqC7lKKjgkCBHPJAHJ0F3waCsdi9tU2rz2 63jAYNbL4t0Zte8GMzGO0jni0Exxxpug1UQ8I0WgUZIIJtgHUmDThox0ndIi4gtK2ujm y0EUUM+YYeORfEACW3NKiJxPRqT3qySmcfZhg56u3ZpWfPzzt8HtmpeRalIDpoMQygHx v7XuP8ceX+Bk8jXvLwF6TCw9OztEX211WpaPxXfAFojD9+2CP1r48FQd4S+UVkramPdA Ao7g== X-Gm-Message-State: AOJu0YxgqHUvRKRKFxl9sbh73W7ltNGzHkWc4FJm+Anlmv9ksJyyz6gR w5dc9DgdpfrRdLSEG6Si4iC85/Esmlu/er8mtqHkhA4s2qlrXdfbOQROgomQULgNEbg7STWuH/Q KkHxPyle0s1XxCdch3LGZ0tjkMjU+iHETHA== X-Gm-Gg: Acq92OFMI9rW9vMt8pSBimAmhPHHzqvtsH92+x5wnf8V6elop/avi+piec1wqfnM3gx hzeq3IWKHSLA/C2RpFEOxUN4zyvsbAJaK6Csl8hE/HcHVCzNVoecKUgK+4/KGoUOWBgfi8v6AEU BmstOLKOXRQhQNlIPXgLmd7G5btq62yoQ/4xzNMIWNQdsXMRMu1HTq1GiQaaVSI1nebukzxiCn9 NwX7GwF10HOoGn1jNhjI1PJChBJuyi/ml+JtDFW+t3KM/4E/dSBC0DWeBw9TI0PkG+9eRHODVJY /qcFeJCXteRfHvH1fioOye4F X-Received: by 2002:a05:6512:6d2:b0:5aa:116c:411a with SMTP id 2adb3069b0e04-5aa323a9cd2mr1220484e87.22.1779459845465; Fri, 22 May 2026 07:24:05 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Raj Date: Fri, 22 May 2026 19:53:51 +0530 X-Gm-Features: AVHnY4Lv9x_XvmhdIHPqsYcIu3w58SD4zYtpu99dSfZQJN40Z_il8VN2GnNyJVQ Message-ID: Subject: Re: Partitioning table - Update on partitioning key To: Ron Johnson Cc: Pgsql-admin Content-Type: multipart/alternative; boundary="000000000000fb2c25065268c746" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000fb2c25065268c746 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The error occurs, due to updating the partition key column. We recently migrated from oracle to postgres. According to my research, columns that are updated frequently are not best candidtae for partition key. With isolation method read committed, if there are concurrent updates on the same row in different sessions for example( may be updated on different columns out of which one update is on partition key), updates on the partition key, may cause the row placed to New partition. Now, because of MVCC the second update may be looking for row to update in the old partition itself and that's when we get error. .. On Thu, 21 May 2026, 23:20 Ron Johnson, wrote: > We'll need to see a "reproducer" (aka short bit of code that reproduces > your problem), with the output pasted here. > > On Thu, May 21, 2026 at 12:12=E2=80=AFPM Raj wrote: > >> No, updating the partition key (say colum created_at)....when u update >> the date , say change march to April, this record is in new partition a= nd >> we get this error >> >> On Thu, 21 May 2026, 17:12 Laurenz Albe, >> wrote: >> >>> On Thu, 2026-05-21 at 16:45 +0530, Raj wrote: >>> > Update happing on partition key. >>> > >>> > And we get error 'Tuple to be locked was already moved to another >>> partition due to concurrent update error.. >>> > >>> > What's the best solution to handle it? >>> >>> Could you give us more context, like the exact statement and a >>> description >>> of the data it is operating on? >>> >>> If I had to guess, I would suspect that your UPDATE statement tries to >>> modify >>> the same row more than once. >>> >>> Yours, >>> Laurenz Albe >>> >> > > -- > Death to , and butter sauce. > Don't boil me, I'm still alive. > lobster! > --000000000000fb2c25065268c746 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The error occurs, due to updating the partition key colum= n.

We recently migrated from o= racle to postgres.

Accor= ding to my research, columns that are updated frequently are not best candi= dtae for partition key.

=
With isolation method read committed,=C2=A0 if = there are concurrent updates on the same row in different sessions for exam= ple( may be updated on different columns out of which one update is on part= ition key),=C2=A0 updates on the partition key, may cause the row placed to= New partition.

Now, bec= ause of MVCC the second update may be looking for row to update in the old = partition itself and that's when we get error.
<= br>
..

On Thu, 21 May 202= 6, 23:20 Ron Johnson, <ronljo= hnsonjr@gmail.com> wrote:
We'll need to see a "reproducer" (aka sho= rt bit of code that reproduces your problem), with the output pasted here.<= /div>
O= n Thu, May 21, 2026 at 12:12=E2=80=AFPM Raj <rajeshkumar.dba09@= gmail.com> wrote:
No, updating the partition key (say colum crea= ted_at)....when u update the date , say change march to April,=C2=A0 this r= ecord is in new partition and we get this error

On Thu, 21 May 2026, 17:12 L= aurenz Albe, <laurenz.albe@cybertec.at> wrote:
On Thu, 2026-05-21 at 16:45 = +0530, Raj wrote:
> Update happing on partition key.
>
> And we get error 'Tuple to be locked was already moved to another = partition due to concurrent update error..
>
> What's the best solution to handle it?

Could you give us more context, like the exact statement and a description<= br> of the data it is operating on?

If I had to guess, I would suspect that your UPDATE statement tries to modi= fy
the same row more than once.

Yours,
Laurenz Albe


--
Death to <Redacted>, and butter sauce.Don't boil me, I'm still alive.
<Redacted> lobs= ter!
--000000000000fb2c25065268c746--