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 1wF3mm-004hst-1M for pgsql-hackers@arkaria.postgresql.org; Tue, 21 Apr 2026 05:36:36 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wF3ml-006HPQ-2E for pgsql-hackers@arkaria.postgresql.org; Tue, 21 Apr 2026 05:36:35 +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 1wF3ml-006HP9-16 for pgsql-hackers@lists.postgresql.org; Tue, 21 Apr 2026 05:36:35 +0000 Received: from ss11.activegate-ss.jp ([223.27.119.27]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wF3mh-00000002FNf-3iyT for pgsql-hackers@lists.postgresql.org; Tue, 21 Apr 2026 05:36:34 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lifull.com; s=20260316104901; t=1776749791; bh=RK0VnA8sY6yi/uHZrRAdytJC3ZpMRGtsIk7Dr+O7cfc=; h=From:Date:Message-ID:Subject:To; b=hFmExq+cwh8NByErkVjFSl4/OtMOLU/4SWS4iBmHBEgy1DSnzLYzF1miwmxXRVa0k yPiHjQmscy34atuX/8v9HZBQiOuFJkUl63VXLB1XwDnyYgNggzG7ASKwEbY7XceOUR BecUO3g5/xderPLBAYLt9AL1LQn22a9USFkdiDJY= Authentication-Results: ss11.activegate-ss.jp; dkim=pass header.d=lifull.com Received: from mail.activegate-ss.jp (agproxy-out15.ariake.ss.jp [10.16.39.38]) (envelope sender: ) (not using TLS) by ss11.activegate-ss.jp (Active!gate) with ESMTP id VOjw17842B; Tue, 21 Apr 2026 14:35:50 +0900 Received: by mail-lj1-f200.google.com with SMTP id 38308e7fff4ca-38eeb467db3so9146441fa.0; Mon, 20 Apr 2026 22:35:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1776749747; cv=none; d=google.com; s=arc-20240605; b=T6+Ow0ZS1jfIuX4Pdxp7UYwdcj6dgCBpp62idCVV5ZDce8yLMeNWdcVIRgt8eu5A+C Ohspd/HWL/OZ+9Vdj3gun+uNsi2rUmvz8ppTnGg91Kl+CwdoQUK3/ExUwZRJiaLQ47PM xwHA+jn46v/aXFWK6cG5Viu8WSOeubMIoWC6T7XcJ2BYX/jpMPl4lterCFfhHNFRpbX8 Q5OG6h7i4/M+05n3R66xnN09Ngwyn3BEd6XcLrxztpeNt96Iv8S4gmvSzqt1CKxDBpyw a+jYG8L6UpUBh0MYHyHp1UHw3mr93L3qzIC0dQh8e/ahaMQJOieAgbFIjCurd+8pIHKF jkkA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:to:subject:message-id:date:from :mime-version:dkim-signature; bh=RK0VnA8sY6yi/uHZrRAdytJC3ZpMRGtsIk7Dr+O7cfc=; fh=nwNxTtLLPTU0ewfLM7SSbrjMajMl+wwnFkCY/fi90vE=; b=cxRfA6+ofIZ5dnIBoCOOWEgVodqCI7EVjVdjKpWL5/PG13PtHuP25uNPVxuOGue8tF RPRSKjRkiVmcN6kCEN2TJSOLZ9Lj9CLLtgqy1ooz5btwVb3X6JvxIUB2FgDKlYZ4yTBE oTU8+7pV2T3k1RMAKkB4pLB4/7MNemxDu5To04q4EEvTgQb3jK6oLQUZb0RodjOICbOI JwgIFMHf9AXo47IqJlgrGMvDJWx+wh7PpW+sz+w6/2wqdSdgrkZBtwI2INYT3rPhzYim yxul8QiN8gJ/xoXKqEOD42uEeZH7in9U6HqNyZ0uo4udOjEP/yWoBdpOvGcb5fo2+Pem NMoQ==; 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=lifull.com; s=google; t=1776749747; x=1777354547; darn=lists.postgresql.org; h=content-transfer-encoding:to:subject:message-id:date:from :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=RK0VnA8sY6yi/uHZrRAdytJC3ZpMRGtsIk7Dr+O7cfc=; b=C8EEJDMF6DltWw4O56LqEF4lldToi2huYddEz8KeewH6YWUI2+iE2zDC2PGQpESBi8 vcGKr4M+E3XfCq3srx8W2NexN/D7YPYDHaVwXrHD7ob/Cv0xUjUqfYkh5VxBOXErY1GH +9kS9dbDlvSTt1nz/FnajKy7LibaO0cic1X5K5SikEG5H1wc61o+ao2ayAFwT+sm6x9N FWqIFYj6TmOvXw+1ld3v3+onaY4cn4cxZWq2LQJYN7NP8NGINbw+mFA1NZMkDO4atkyi Xj+P13zB7XoD2FZAha9URJHIwR4nUcLS5DxZw1tyNNocQVEnGKBMnd8SrVNByxDktvgh w0BQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776749747; x=1777354547; h=content-transfer-encoding:to:subject:message-id:date:from :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=RK0VnA8sY6yi/uHZrRAdytJC3ZpMRGtsIk7Dr+O7cfc=; b=FOxhCAES21RaKODFBcYEtfrFr4kCSd4w3VR8GX26Wvy2pJ8pzFM7rNy9cIq2a+o0z7 mMbX6fFnYC0ZGtOyZ6F7kZke2UdqhI1H4e2Yo88jK5hGeOmMpv7H+lun3uYKZLqudovh S1T/xdZlL+4Qrcdu/iGOpDlh6xp0ZFZMsT4tfAwzhuPbMRN8NZ2K+DW60mEy22xs/wET 8Vj3qI9iEtzq1N/EZWvy5mA66xmuoYVZkes/XczZenk/ZieLzEmHLnKanFijZ3b3IZLv Pi26Cbbh6v4wHRe1Dn0++PlSmk5LTvemxuoo/ZWS5sUCCCvfloLFqmEXk8EBkFc2sJwh KLqA== X-Gm-Message-State: AOJu0YwUW2/zCmg8TA+tzRCxH6/97PEGxERcEhvwWO6OCWNKZ18KDSLo XMSxXOhOPWaPY7zI0eYsqPm/Cgx/4pkiCd3uxa9G/hGob6fgYmH1RP2LMvaYa6xndSHiexz4bxC IwxVP5HpBaNcr9fSchm92nOptJt4aP3R+uFedjwQzrSLBx3eSXubSrcQNKoU2gOUveFhVb185q/ R2Wfgdw1/KAudfwTAe77lZ25FxSYdNiBE9h2i/LSMFqF8yR29xyn7w2FMb7xvwCg1kWGdsO074Q N3XGF1/pbSa X-Gm-Gg: AeBDievlVtAZUeR/HFGLQLBsCWgHK2dOG/NTW2lKcB7FTBgo0XcqNcmWKbNXVLjjAAg Gl9DdSMKZBjKSlTWTM9wi/C3+eZnf72rXsREb1gqKHqNUQVMIUXaD274RjJK7F4iCGH4n7kvMGr YTxh/hX1D456ODHZ0iyqLTlVJVPZlvPAN/DQfYQBOtsu3xGbQOYlz5sxmKiMYz3r0IskLgr35ec BiUUxYbxHEbqYsOwWM= X-Received: by 2002:a05:651c:41dc:b0:38e:85a3:fdf5 with SMTP id 38308e7fff4ca-38ec7aa49c7mr48689221fa.18.1776749747440; Mon, 20 Apr 2026 22:35:47 -0700 (PDT) X-Received: by 2002:a05:651c:41dc:b0:38e:85a3:fdf5 with SMTP id 38308e7fff4ca-38ec7aa49c7mr48689151fa.18.1776749746938; Mon, 20 Apr 2026 22:35:46 -0700 (PDT) MIME-Version: 1.0 From: =?UTF-8?B?5Y2X5ouT5byl?= Date: Tue, 21 Apr 2026 14:35:35 +0900 X-Gm-Features: AQROBzC6ntG5z4DGYOA5udO7HRGCw9VwcsIpFEF1AXj23h6eU_d7vxIfXzQnzfw Message-ID: Subject: Warn on missing replica identity in CREATE/ALTER PUBLICATION To: 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 Hi hackers, CREATE PUBLICATION silently succeeds even when target tables lack a usable replica identity, while the publication publishes UPDATE and/or DELETE. The error only surfaces later at replication time: ERROR: cannot delete from table "foo" because it does not have a replica identity and publishes deletes This gap has caused real production incidents =E2=80=94 in one case, a CDC pipeline using FOR TABLES IN SCHEMA included a table without a primary key, and replication stalled for hours before the cause was found. I'd like to propose emitting a WARNING at publication creation/alter time when this mismatch exists. The check would cover all paths: - CREATE PUBLICATION ... FOR TABLE / FOR TABLES IN SCHEMA / FOR ALL TABLES - ALTER PUBLICATION ... ADD/SET TABLE / ADD/SET TABLES IN SCHEMA - ALTER PUBLICATION ... SET (publish =3D 'update, delete') The approach I'm considering is a publication-level check that runs after the final publication state is known, scanning the effective set of published tables via GetIncludedPublicationRelations() / GetAllSchemaPublicationRelations() / GetAllPublicationRelations() and checking each table's replica identity. I have a working prototype for the FOR TABLE / ADD TABLE paths. A few open questions before I post a full patch: 1. For FOR ALL TABLES, the check would scan pg_class. Acceptable for a DDL operation, or too expensive? 2. Should we cap the number of warnings when many tables are affected? 3. Should this be controllable via a GUC, or is a simple WARNING sufficient? Thoughts welcome. -- Best regards,