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 1whcEI-000KRL-1L for pgsql-hackers@arkaria.postgresql.org; Thu, 09 Jul 2026 00:03:02 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1whcEH-00A7Z7-03 for pgsql-hackers@arkaria.postgresql.org; Thu, 09 Jul 2026 00:03:01 +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 1whcEG-00A7Yv-2P for pgsql-hackers@lists.postgresql.org; Thu, 09 Jul 2026 00:03:01 +0000 Received: from mail-qt1-x82b.google.com ([2607:f8b0:4864:20::82b]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1whcEE-00000000N1h-2RPF for pgsql-hackers@lists.postgresql.org; Thu, 09 Jul 2026 00:03:01 +0000 Received: by mail-qt1-x82b.google.com with SMTP id d75a77b69052e-51c2b2c9eccso2230311cf.2 for ; Wed, 08 Jul 2026 17:02:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1783555377; cv=none; d=google.com; s=arc-20260327; b=MN/87n4fgUv7a+OS4RqWk6k8qBkgCNxY8yj+zgW0kmGi49ZsyBt3Uw1yWC/uXeTEeE uFbj1GOsxuBVfrmARXuVstcmkX6IPayLvBbE/gYxerc3td1zp0SMBl+hZd0GvKxbOiK9 ZLpJbPu0wjzEdTaf3W8Tlut+HIZ318g9owNmgv7jEloG6M6TuXX9PyjNwNdwCbQibkCY dmSneFBnJShiLWENOeWa0NPFm1u/JP9ZaOT0aVhw8AMGxBDeP9BUDsC2S9tdIR8gd/Gw lEy+G42bvgX+IvNwv5MxigNoMutz4JV2RxIjQxx4AIKc1IrcoiBOeKGuQuSOVlb99zX7 Lhgw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=XBxPHMiu0tLdxPm3oeYLhXnA6LukZ9r9RUjp4pv9UBs=; fh=15x3VzDPvy69YMjAmNzC93xzXTQ4yRkrX801gFUk3mA=; b=DgACpvgXdh/ch+i57qUhQdpjrg0RRnFhhhgw/zaJI16uOOO9uVHEEAY8VGczB296xH 9V54f+WLLolP5peLQuTBHwtDiy4S9Szha9B+vkjcyTYBw4+Zogw8a6VZAKIr7Fe/NyNE sZGkO+I8Isxr/7uqTh5QxB84H/xYhDPtazVA2KuGmY72oTfACDn8/F8bdMVXcwpvgImJ zqJHWiDeL1gMmi9xxBtyCH/xULofGXBa/jeClwSntIQbJVN5d0KKNuV+GyBEaDqvzOxO 6TltB5EMSeLMsS57w5YRKxdvpspYopKIDMY4rMxKjGbn1HwQOK6BfIULiDYWn7ywafG2 KZJQ==; 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=1783555377; x=1784160177; darn=lists.postgresql.org; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:from:to:cc:subject :date:message-id:reply-to:content-type; bh=XBxPHMiu0tLdxPm3oeYLhXnA6LukZ9r9RUjp4pv9UBs=; b=EgqymKq/WPqObpkF8rtxBPxbSUkg4jlCaOM8A7zGFbzy16oHV/iG8L/kuYrUsUMAfW HHWHLK0uhOVn4lMusV9qtB1mt/kE0XJIGz9t0y7FMk7KSIohVsnB6HwFQKEswWfP9GKk 1psP5QfzGRudyYZZ+eNu7ryNAjP/nni8b1+o9ZlmrtsEyTh2i/oV7nsJURXwdyeU3ww/ 90U4z4fmfVEcm+X55d0N7y16I7XTSzlaqj206qK2edCWYFSbtL94ePXUrRammUGq404M GdtVB8LEeDpK4o/cQkn/qoDI45p95wuS/ojCAVHnV/tTK60U65Qpi+fAhTmLpW7gzrIM FJVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783555377; x=1784160177; h=content-transfer-encoding:content-type: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 :content-type; bh=XBxPHMiu0tLdxPm3oeYLhXnA6LukZ9r9RUjp4pv9UBs=; b=KMsSBb+Id4uBskRddM0qEPKq8QPuelKgfCjSOMuFVSAy7OczBm+ff6CRPxgfhbBqzy Y25ZN9GlAJpvtHDhOlRjtZkGmijKBBMALrNUGCdpVM9yUDBYjTOxYsW3lqrblwdH6zmg iAcGOTXs8F4w6d3j5YO0FeUYKUpS3vJ+hz+eImHyZK1AOfaVF6vU8KPBFRU27Ccyv5OJ sijEk3YPwNM516h5k+QTvZM71CqKu0idq2RTTcn/UEXyX3UQiqpkEhuY2cfvJIxUlJxB T/Y7JjSSzKQEKLse46XC1nAihPxq6HHg4ULE/ZTWN/tgxJnO3AGmKmgJ8FfKHs7F9nS+ qPUg== X-Gm-Message-State: AOJu0YwdjHkqP5S0bOZnLDHyQBEcCUPUUKdg36uak7c26jiFqQlgk63j l5Kf8+1mX9hIqlnU5Ggifiti1480KgRD/2zFlO35PtTNX2MTKkrQiE9H3yNVKBN0oA0QbgvM3ir 0/pJo5U1wn/gCjhDJMRvmqGuk0fMK7W4= X-Gm-Gg: AfdE7cmyr/eCbKbh1zG/gaJIhXaspM/cbRFYMyhoyBnW/wBtlSG70AIv61oUv+EOWyK i9HjCOThyGjw+o1oLDaVkDMCMBalLyBXD+9q+AwmBge4iERamybg9632C7XMrM+yHCXJgGz+HDg obumbyCD4lVujcQAYIQB9+WgSVRdcL6VIi3AIOJiMylVoCv2GuxWrSqsZmyEFDeCfTPsc7Iaj9q jVtp4sSRiOPy41Yd3wHPxTF1OX6Xu1P5on7fgnWvb7pQH2tnyw/7+ZAJWm0FRaxtJdPt5H8DBu+ bbq8a+iUigCi2EMX6501pdP2PrDkDhmlQyu1B84zpIt+jiLmfPvHzg== X-Received: by 2002:ac8:7d91:0:b0:50d:9e8d:9837 with SMTP id d75a77b69052e-51c8b2addaemr52493611cf.11.1783555376777; Wed, 08 Jul 2026 17:02:56 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Peter Smith Date: Thu, 9 Jul 2026 10:02:29 +1000 X-Gm-Features: AVVi8CdZzVo8WQFWO47eqQ37NOyZpsHq5LqCIXrXUIwtcZ7N2uHdUtYR-wdMERY Message-ID: Subject: Re: Per-table resync for logical replication subscriptions To: Cagri Biroglu Cc: pgsql-hackers@lists.postgresql.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Jul 8, 2026 at 8:55=E2=80=AFPM Cagri Biroglu wrote: > > here is the WIP patch for the disabled-subscription case. > It adds: > > ALTER SUBSCRIPTION name REFRESH TABLE table_name > [ WITH (copy_data =3D true, truncate =3D true) ] > ... > Open questions if this direction makes sense ,I would still like feedback= on: the command spelling > (REFRESH TABLE vs RESYNC TABLE), and whether the enabled-subscription > case is worth doing as a follow-up (it needs the running apply worker to > notice and re-read the reset relation state). (My feedback only about the syntax question) As you said in the OP, this proposal is a bit like a table equivalent of "ALTER SUBSCRIPTION sub REFRESH SEQUENCES". IIRC we went through similar syntax debates when that command was being developed. Some alternatives were proposed [1] ALTER SUBSCRIPTION sub RESYNC PUBLICATION SEQUENCES; ALTER SUBSCRIPTION sub RESYNC SEQUENCES; And, then more [2] ALTER SUBSCRIPTION sub REPLICATE PUBLICATION SEQUENCES; ALTER SUBSCRIPTION sub RESYNC PPUBLICATION SEQUENCES; ALTER SUBSCRIPTION sub SYNC PUBLICATION SEQUENCES; ALTER SUBSCRIPTION sub MERGE PUBLICATION SEQUENCES; It went back and forth for a while... Finally, I proposed [3] and gave some reasons for just having: ALTER SUBSCRIPTION sub REFRESH SEQUENCES; And that's where it ended up... ~~~ If your proposal is to proceed, then IMO it would be better to continue the same pattern, avoiding introducing new keywords unless absolutely necessary. So, your v1 patch syntax "REFRESH TABLE" looked good to me. A similar reasoning to "REFRESH SEQUENCES" [3] can be used to explain it. =3D=3D=3D=3D=3D=3D [1] https://www.postgresql.org/message-id/CALDaNm30iA_N4Dfeyp__YdLnbm9oatw_= %2BVyCfNfbQmZiS_ybCw%40mail.gmail.com [2] https://www.postgresql.org/message-id/CAA4eK1JJUv2Kykb%3DJvdTzq%2BqDzkb= D3m%2BYPAF6qz6Sm-qJ%2BwF8g%40mail.gmail.com [3] https://www.postgresql.org/message-id/CAHut%2BPvOmCe2fO4LPwJtROierhGLtH= Y%2B%2B%2Br9PXF8%3DLLQ2m%3DAXw%40mail.gmail.com Kind Regards, Peter Smith. Fujitsu Australia