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 1vAr5M-006cOc-DJ for pgsql-general@arkaria.postgresql.org; Mon, 20 Oct 2025 14:42:07 +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 1vAr5L-001XRI-9M for pgsql-general@arkaria.postgresql.org; Mon, 20 Oct 2025 14:42:06 +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 1vAr5K-001XN4-B1 for pgsql-general@lists.postgresql.org; Mon, 20 Oct 2025 14:42:05 +0000 Received: from fout-a7-smtp.messagingengine.com ([103.168.172.150]) by makus.postgresql.org with smtp (Exim 4.96) (envelope-from ) id 1vAr5H-002o2z-1X for pgsql-general@lists.postgresql.org; Mon, 20 Oct 2025 14:42:04 +0000 Received: from phl-compute-09.internal (phl-compute-09.internal [10.202.2.49]) by mailfout.phl.internal (Postfix) with ESMTP id 8E870EC00D8; Mon, 20 Oct 2025 10:42:02 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-09.internal (MEProxy); Mon, 20 Oct 2025 10:42:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aklaver.com; h= cc:content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1760971322; x=1761057722; bh=swIptlGTJIueMyZgMGMi0LAJCCTDGvfNii8TDvopIuw=; b= hAwzYYuyf9yHkxMG6mIcg7aVmMz6ViVByPrtdcZRyxeeR+y/N95666+ZhwfOf6fe cM9Te5eSVFEM+wNma+OVhwtjGJn5pQq91sYKuoDPc4FQR8rzZUudXyt6zmqJDLV9 NgtZBC9t9idDeA0opq3sDf1ysfHBnVzwKKx0omHsdckbcBWEli3GB/3MNwj7G0NX xHIyB7yHxfdnkkSYXz2A2lvJdLaLqNW0GY5661QzEg/ti5MGIGgVvaROrL7QWT8l LWEufnzklabDy+ei8l7g6K4YjDNg1BKYdFOebhaymzIBe4cIH58acFQtYGV8UiLg 806SkJNAvVDoU/gC8DL9Zw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; t=1760971322; x=1761057722; bh=s wIptlGTJIueMyZgMGMi0LAJCCTDGvfNii8TDvopIuw=; b=gNLT+EeeY8Gpb+ys6 oS5SDsHzQd65J3k1f/0lBQGv8zX5zby7s0T8s46yGqpU0q74/iA0W7JChospMWxO 1NU+wZq154lKnEv5WySh1ubsHEXtnhmj8v4NN+x48JXS68wzar1vLGxJIC7yaujt GlNLhdA1maP+cRMm8GnxSrJh1Y6zHHLH/Z5k1G+gWu4wnsdLz9YRxAfRVSJB3FZK merSFYCmW2skzOWXMKv+7usPRiH1HUI6q47ko27nCrg/MR6VtJ3El1KKr7s0e9AP iMsOEqxKN791rA8NXLmrezFwvjDhlLG2y5zCZFNnvl2Z0clYsHjdi6vb80wxc/oB znklQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggddufeektdekucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepkfffgggfuffvfhfhjggtgfesthekredttddvjeenucfhrhhomheptegurhhirghn ucfmlhgrvhgvrhcuoegrughrihgrnhdrkhhlrghvvghrsegrkhhlrghvvghrrdgtohhmqe enucggtffrrghtthgvrhhnpeffleegieefgfevudehtdfhkeeutdffjeevgeffgeejvedt hefgudeiteefheejheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpegrughrihgrnhdrkhhlrghvvghrsegrkhhlrghvvghrrdgtohhmpdhnsggp rhgtphhtthhopedvpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehrshhhvghprg hrugesrghpphhlqdgvtghoshihshdrtghomhdprhgtphhtthhopehpghhsqhhlqdhgvghn vghrrghlsehlihhsthhsrdhpohhsthhgrhgvshhqlhdrohhrgh X-ME-Proxy: ) id 1v6kk4-0098NR-NC for pgsql-general@arkaria.postgresql.org; Thu, 09 Oct 2025 07:07:12 +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 1v6kk1-000Sme-Ff for pgsql-general@arkaria.postgresql.org; Thu, 09 Oct 2025 07:07:10 +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 1v6kk0-000SmO-RZ for pgsql-general@lists.postgresql.org; Thu, 09 Oct 2025 07:07:09 +0000 Received: from mail-ed1-x531.google.com ([2a00:1450:4864:20::531]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1v6kjy-000oCJ-2s for pgsql-general@lists.postgresql.org; Thu, 09 Oct 2025 07:07:08 +0000 Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-634a3327ff7so1210513a12.1 for ; Thu, 09 Oct 2025 00:07:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1759993625; x=1760598425; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=6JBJljRR3FyPWFo7xPq9B3Mu21zYoQ4jzT9PLi2MY7g=; b=RC/5UOl+I+bBGvk4eBMlkCas2Dz5vI7zPPwD5IPrwH8+26kse0ES36YW/Be46a4KZA AVNQvZ3atRcNmJD5Ff5i9pk5NSjqfLe3b8N/kDVp6nunwX2cLiH2hDpXpvhBWkWsMVN0 4V/Bqa+9R9VrKeEC/xwoZMRoxnYXhxENeAJB69yTbdr50aEr59JZxkgjq021ZIVhhrph w5y3PplWoPBOmDcFXTZHzEPVx3FQFTdkHxNFuFzF/CBrApHCyxTK3ekFE5uGhTQ49fTZ OdDB/rcWM4kq4w0eRuCGL1+kVMWJlAqk/SRbBuPImIaqzobrmU2HWBRiYzXwg0qMsOsy OJIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759993625; x=1760598425; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=6JBJljRR3FyPWFo7xPq9B3Mu21zYoQ4jzT9PLi2MY7g=; b=BZuOXz+lxeF82GC2srWvgZtWURaIaf8b55rVAcmrDgSqDr6aN1TaXm3QMQ1KO5ZWvu aZM1Y/FEq/HX5ajN/ggeu8pkprk6355vQBQ90zug8mhSlfhC82MV9q48QKPuFfOav2XQ /xoNMNTJzBSC4LYf4BAewKcsMFCfEpEsV3oJtMj2UMGBOYHQR6tb9zvaIZIP9lBkdQ2M kSPwq6GAB2efGH1JDbFQtnS9AEWSoOH7yCBjw1FqRq4Q9IgFh1x2xDjuRtiFgQno4bjs RvkkfrDYy5CFlOWwUoUNSYkWII/5vbSItmUaAcNjoIKxwTeQDWEBEuYTF8w74MVaG3dH Ha/w== X-Gm-Message-State: AOJu0Yx4wrLAyMBeRoXuJ5ExZQJjQg85v6Jd9XwxDTAyRVlE2Ro+W9Ti OtvNzPXhjgJ64wX7fiL8SdiD6kSD0mCY6HM2KIxEvZoExS6WlHJjk4oGFYEB/0hqZuJZ3iSegdx e+EqkuMPv8hIpTkvgXzrIt7Q/EB8aAeEDtBNu X-Gm-Gg: ASbGncvgzRd1fv3yVAWXQ7He56KAE1/oWLQ7eDmrg3ynUwUia1KaTUhyrEtSWPAHUom VcQUrI5dJTV9vM/Z6XHdO//aCUyWyhEf5TfuCG69B5rWkQCuNx9yud3Kl7Br+bbrG2cIy195sxT S2BnVZOr/hPfTDEst7G3Te/6/dPESmBwp3OZr2B8wj7z21MrgYJ960CUBFSPBMU2Uf6M5g0jt5M 3itc1UYtq0GtdKQ6xxQZpcrUVzU/LCFpBsCdV2SUUE= X-Google-Smtp-Source: AGHT+IGoJ3elGSuerZtjB3/7908PapRM1jXBlch8yi2W8WysRZMr1qhbE3teJG+yqSoZVsRjDfmUyVE4wn/rm1Uy978= X-Received: by 2002:a05:6402:505:b0:634:66c8:9e6d with SMTP id 4fb4d7f45d1cf-639d5c76e87mr4458067a12.35.1759993624369; Thu, 09 Oct 2025 00:07:04 -0700 (PDT) MIME-Version: 1.0 From: Rajendra Kumar Dangwal Date: Thu, 9 Oct 2025 12:36:27 +0530 X-Gm-Features: AS18NWBuQiDYymd8byubJMmFAgkEmW6ryDOgftUnGG_bc6T7mW-kUaum4cznwZA Message-ID: Subject: Clarification on restart_lsn behavior in logical decoding To: pgsql-general@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000c99fdb0640b4727f" List-Id: List-Help: Feedback-ID: i76984098:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 20 Oct 2025 10:42:01 -0400 (EDT) Message-ID: Date: Mon, 20 Oct 2025 07:42:01 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Arrays vs separate tables To: Rich Shepard , pgsql-general@lists.postgresql.org References: <162e5330-861c-ecc7-45c1-aaa1aff26c88@appl-ecosys.com> <95de5a9b-4dd8-2f7-6e12-98c3d72c52@appl-ecosys.com> <712b8b5c-15d2-e284-a0c0-6263415250c3@appl-ecosys.com> Content-Language: en-US From: Adrian Klaver In-Reply-To: <712b8b5c-15d2-e284-a0c0-6263415250c3@appl-ecosys.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 10/20/25 07:07, Rich Shepard wrote: > On Mon, 20 Oct 2025, Michał Kłeczek wrote: > >> There is also another concern - do you want to make sure phone numbers >> are >> not shared? > > Michal, > > Shared with whom? I run a solo professional services consultancy so there's > only me here the database. That is the heart of the matter, you should do what makes sense to you. If you can get the information you need in the manner you want then don't change things. Given the size of your datasets I don't see that changes will materially affect the performance of your queries. I am pretty sure most of the time the Postgres planner is resorting to a sequence scan anyway. > > Rich > > -- Adrian Klaver adrian.klaver@aklaver.com //lists.postgresql.org/manage/> List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000c99fdb0640b4727f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi PG users. We are using PostgreSQL=E2=80=99s logical decoding feature with Debezium to= capture CDC events and stream them to Kafka. To verify whether the required position to resume from after a connector restart is still available on the server, we compare the processed LSNs with the restart_lsn of the replication slot. From the documentation, our understanding is that restart_lsn represents the oldest WAL position still required by the logical decoding consumer: > restart_lsn pg_lsn > The address (LSN) of oldest WAL which still might be required by the > consumer of this slot and thus won't be automatically removed during > checkpoints unless this LSN gets behind more than max_slot_wal_keep_size > from > the current LSN. NULL if the LSN of this slot has never been reserved. However, there is some confusion around the possible value of restart_lsn. My current understanding is that the restart_lsn cannot be greater than the start LSN of the oldest open (non-consumed) transaction. One of my teammates, however, suggested that there might be cases where the restart_lsn could advance beyond the start LSN of an unconsumed transaction, as illustrated below: LSN T1 BEGIN T1 CHANGE 1 20 T1 CHANGE 2 21 <--- Restart LSN T1 CHANGE 3 22 T1 COMMIT 30 <--- Confirmed flush LSN T2 BEGIN T2 CHANGE 1 10 <--- Start LSN of unconsumed transaction T2 CHANGE 2 11 <--- Last processed LSN T2 CHANGE 3 12 T2 COMMIT 40 Could someone please clarify whether the restart_lsn can indeed have value greater than the start LSN of an unconsumed transaction, or if it is always expected to be less than or equal to it? Thanks, Rajendra. --000000000000c99fdb0640b4727f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi PG users.
We are using PostgreSQL=E2=80=99s logical decodi= ng feature with Debezium to capture CDC events and stream them to Kafka. To= verify whether the required position to resume from after a connector rest= art is still available on the server, we compare the processed LSNs with th= e restart_lsn of the replication slot.

From the documentation, our u= nderstanding is that restart_lsn represents the oldest WAL position still r= equired by the logical decoding consumer:
restart_lsn pg_lsn
The address (LSN) of oldest WAL which still migh= t be required by the consumer of this slot and thus won't be automatica= lly removed during checkpoints unless this LSN gets behind more than=C2=A0<= /span>max_slot_wal_keep_size=C2=A0from the current LSN. NULL if the LSN = of this slot has never been reserved.

However, there = is some confusion around the possible value of restart_lsn. My current unde= rstanding is that the restart_lsn cannot be greater than the start LSN of t= he oldest open (non-consumed) transaction.
One of my teammates, however,= suggested that there might be cases where the restart_lsn could advance be= yond the start LSN of an unconsumed transaction, as illustrated below:
               LSN
T1 BEGIN
T1 CHANGE 1    20
T1 CHANGE 2    21  <--- Restart LSN
T1 CHANGE 3    22
T1 COMMIT      30  <--- Confirmed flush LSN
T2 BEGIN
T2 CHANGE 1    10  <--- Start LSN of unconsumed transaction
T2 CHANGE 2    11  <--- Last processed LSN
T2 CHANGE 3    12
T2 COMMIT      40
Could someo=
ne please clarify whether the restart_lsn can indeed have value greater tha=
n the start LSN of an unconsumed transaction, or if it is always expected t=
o be less than or equal to it?

Thanks,
Rajendra.
--000000000000c99fdb0640b4727f--