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 1ugsxY-008IKk-Df for pgsql-general@arkaria.postgresql.org; Tue, 29 Jul 2025 22:38:13 +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 1ugsxV-0052Yt-2Y for pgsql-general@arkaria.postgresql.org; Tue, 29 Jul 2025 22:38:09 +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 1ugsxU-0052Yk-Lr for pgsql-general@lists.postgresql.org; Tue, 29 Jul 2025 22:38:09 +0000 Received: from mail-qt1-x82a.google.com ([2607:f8b0:4864:20::82a]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1ugsxS-001SJQ-2h for pgsql-general@lists.postgresql.org; Tue, 29 Jul 2025 22:38:08 +0000 Received: by mail-qt1-x82a.google.com with SMTP id d75a77b69052e-4aeb2f73fc0so28452041cf.2 for ; Tue, 29 Jul 2025 15:38:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1753828686; x=1754433486; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=SqBqOooFKT0c3PvkZ0Ni91D7d2cGiIxHeSb/CmbBnQM=; b=cSvCu0ScF9GsA6T7ldBkZl46D28Lt5okymZ/sb2zpQgtIzgdB5+9/qkplXo4dIBclG RWs74DjFRp3+rGiHOkaDI0+8iUj0Cwh/CRbXEKvXzsUTyOkqkfaFvE47QaGBiPso+qe1 7Laix6AAKRd9wsM6ZJZ7/ecLt1ImkAupLPDi+tTobAzV/D7NUuuyNZnoEAi7uaxG23Bj 53rF2wKLqdzl83mmfr3RtltOb1P3hrqiOXy9/l51CBmeS3pAPYiUufhGA5uPbt062Yta KYNyq+C9BMwkcxeWo1clf+hTw2chF52p/cTmG+bDEPyAqYBN9anpgGxOGxCh7cdahf1v 5BSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1753828686; x=1754433486; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=SqBqOooFKT0c3PvkZ0Ni91D7d2cGiIxHeSb/CmbBnQM=; b=gtXqa2WwltD+Xe2yKlTIxIAJb6bDn4oGQVk7aajVbAbg2sgoKDiHEnPF9GuI7VvXCB Q80FuRM9BNtnVTC87brLLesZx1HSuPCkgd/nHm7t7WEKHa8+UqpZ0v3clLGokM2MPHcW uDrJUP7o+o0vSs53ymyolorlzhVFNftmd/I7bxdhnwWum+gvECcekXhPEOeHVwQyhT5a WqbNkkS8CLi+mtRZ+h7qQXkSr6qd4LzbBTL/8oL77GpvmrmtjzUZak5eToW1lfIQ8sPz UhaElCH2Gle9+TCA6biV1/h3eOupVHZJA4fLfo5HPbpeGKI7jo3bTBrWaSWiqJp9tNCA aSlQ== X-Gm-Message-State: AOJu0YzbSDHyJV8CPjv5NnVXsKRz5bcSmPSdph+KVCQvz6sr83lWmESG dNx5oVkI3FZ0JQg52ddKwj9DRzAvbRSbwCPlc3Nz5Nvx+hSRjQBigr/zsUhU3DOlqKbpvAfiGjF ZHH0/BTuxZCg4AXoNvfU1AKXUlP4wZjC0O5apAb8gRjGC X-Gm-Gg: ASbGncsyYz1P8hipnhRKQBVqkhnYJN2YXWXDvRABYoaoOsJ5OYB+NNajnnSxwy+YHiq /5WSQHQSD74kSMjOQvE7klZr7YPCdniNlexSuSESyUEp9got0gYwyYbzs4lHqP+CPDZsF7viaw9 eEsKtHo9i3zhtNnG28FfzFkzyHazk/3VEkQlDaw04yuh4TOkStw/1xBoO4QWlcH3NZ+A== X-Google-Smtp-Source: AGHT+IHqFgr+W0y54BqMlMRTrXuouFo/MVzTTC99WldnQmfmHB8dCfwBR8LCEqY9QalZw5NpepOCepB8Dou39aungjw= X-Received: by 2002:ac8:5d4d:0:b0:4ab:9586:bdd8 with SMTP id d75a77b69052e-4aedbfabea8mr22375711cf.55.1753828685443; Tue, 29 Jul 2025 15:38:05 -0700 (PDT) MIME-Version: 1.0 From: Akashkiran Shivakumar Date: Tue, 29 Jul 2025 15:37:54 -0700 X-Gm-Features: Ac12FXynKoXs49qQF2q0ONkcLjHRRrVC9V74WHGzHwfSEpXHmO1gy72gv6Yud9E Message-ID: Subject: Can postgres replication slot using pgoutput release multiple CDC records for a single update to a particular row To: pgsql-general@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000caf7eb063b190ff2" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000caf7eb063b190ff2 Content-Type: text/plain; charset="UTF-8" Hello, I have a postgres database (major version 13) and am doing CDC by using a replication slot with pgoutput. In our data lake, we see that there are multiple updates (3 in this case) happening to the same row as part of the same transaction. This doesn't make sense if we look at them as separate updates. The expectation was that the row was updated once and a single CDC record was pushed out. I haven't completely ruled out whether multiple updates happened in that transaction but I wanted to ask the community if it is possible that a single update statement could spill over as multiple CDC update records by pgoutput / postgres ? If yes, could you possibly point to the testcases or code where this might happen? Any blogs or suggestions are welcome. LMK if you need further information P.S: Each update seen in the data lake changes at least one field in the row. The entire row with all the columns are pushed out for the 3 updates seen in the data lake. From the application perspective, it makes sense if the 3 updates were merged into a single update record Regards, Akashkiran --000000000000caf7eb063b190ff2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,=C2=A0
I have a postgres database (major version = 13) and am doing CDC by using a replication slot with pgoutput. In our data= lake, we see that there are multiple updates (3 in this case) happening to= the same row as part of the same transaction. This doesn't make=C2=A0s= ense if we look at them as separate updates. The expectation was that the r= ow was updated once and a single CDC record was pushed out.=C2=A0=C2=A0I ha= ven't completely ruled out whether multiple updates happened in that tr= ansaction but I wanted to ask the community if it is possible that a single= update statement could spill over as multiple CDC update=C2=A0records=C2= =A0by pgoutput=C2=A0/ postgres=C2=A0?=C2=A0

If yes, could you p= ossibly point to the=C2=A0testcases or code where this might happen? Any bl= ogs or suggestions are welcome. LMK if you need further information

=
P.S: Each update seen in the data lake changes at least one fiel= d in the row. The entire row with all the columns are pushed out for the 3 = updates seen in the data lake. From the application perspective, it makes s= ense if the 3 updates were merged into a single update record

<= /div>
Regards,
Akashkiran
--000000000000caf7eb063b190ff2--