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 1vlLCB-00ABQt-29 for pgsql-hackers@arkaria.postgresql.org; Thu, 29 Jan 2026 06:08:00 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vlLCA-006et5-2M for pgsql-hackers@arkaria.postgresql.org; Thu, 29 Jan 2026 06:07:59 +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 1vlLCA-006esx-1J for pgsql-hackers@lists.postgresql.org; Thu, 29 Jan 2026 06:07:58 +0000 Received: from mail-pj1-x102f.google.com ([2607:f8b0:4864:20::102f]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1vlLC8-000000010us-28ed for pgsql-hackers@lists.postgresql.org; Thu, 29 Jan 2026 06:07:58 +0000 Received: by mail-pj1-x102f.google.com with SMTP id 98e67ed59e1d1-352c414bbbeso1072178a91.0 for ; Wed, 28 Jan 2026 22:07:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1769666874; cv=none; d=google.com; s=arc-20240605; b=N1In/FUYXvZSmhpRAZzcH8amOXCFkz5EiEhLUz4AWPgpkKxGG3rX8i40erynG54ElR sosiSl5xGceEtwyAu1YsBE6umTjSNKcafMwDgNwWG2AN2S0PBKO+yomaXvYB81k3pWfD fqj0ZSDGFsIQl/f3e7EjHIQssVK7RNknuzp+88JD6aR35FfONG93cHUtikDlFKPtEANL vq6MjhAq/yjfU6cnlnqcSNM0CGOnbkbguZrbwhn1XgtCR+TaT/hwQaiDHavPQyekfZmb wUlZKphb6yimlgXhUZwS3TQey8keamm/aoJ2O71zCRvrut/zpvwOJjfVZ1sx6L/K5vnY rU2w== 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=/MkR3IXeZRDo+qDPGurq7YKatAi7GqEYeYdBIYWqHQ0=; fh=cjAIQm5KFf2HS7bjZU9nx1+TWMDQNXBbdilGEBVuLOA=; b=FCN32XiPC73Pv8C4RhIEEEhILgJKEbbQZfpUiyfi1NdJU1RoiLx0rzbm7legYLLVCE gX7a3kbJylz3PiIU6ZHzj3fjnYHsO/FbY/GbUX/vOyKNOo9pBWjPDa3wBj4ClcJTsx02 rEFScZGcLV2KfMKh9YHhmvqjtgXSS9g+s3K/ZyNYlVAE7vsnKkZDHHNtVTu0TWfZAyxX 2InLjUPYX/SnzmMw41D5RcQoMMkh+14N7uJmrT+p1EyLci5UVgrkInkqvmRjAAq3vroa x3PdsiYYKSouDncZobHRdgJ3iZSYyerDB2LOol5x1jyhYu+jCWI0XFkWQ5nT1PjRzQcL fqYQ==; 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=20230601; t=1769666874; x=1770271674; 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=/MkR3IXeZRDo+qDPGurq7YKatAi7GqEYeYdBIYWqHQ0=; b=YgtQ9oGNaTv8a/MLAnlAbz9+CKdpYlhS5squ1+X0LixENvjcxkh4gGjsSCkb3LhQoV AEInGrD64qs6l2bULekvcxmzMDIgY3F7xsqrKEOBNqw9jtXYDYRKUiCGUuPLS0z8OuTw REBZsOL/EYT2VDgpyDBvuFbUyGy08YRVPXl6NSyKK2cKWYGzP7GdmHQ+yR11a60jXC/J vB7N1vQfPJs6agGRJDWiQGBq8qRe6nIkITzkwjJEC9rBzeba9FSsEUXF+NxViSyyeSsM x/cnboPtYsYjdfL7gZQagiOw3rS/6aUwSl0za9dK2+gb7nNAkz01Q6f7Uq6HYtyyC2Aj P1eQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769666874; x=1770271674; 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=/MkR3IXeZRDo+qDPGurq7YKatAi7GqEYeYdBIYWqHQ0=; b=gQSF0Ychr7pODyYDKomV4ZK8eTziq3HbaCefK0OeCo0RMTi6M7l5Xf5yDvyTfzu20r ZSaxG/PrbAqI9zbtibc5XvMvqG8icxwYu2hT027/1fnvcaWVBXBf8R/LavqhdqdRq2Bo NF8Gm1je4h5p3U2GS18yWVr1Y6M8zsKyNh5pIJuD6YFOpfqmBc8KYASiq9t2EktGEcVL UVE5j32vwXJ4hXnd76WaH0igzXf5NugE4ITA2EFZgwfHT11T/XcE6LbAxhfxK6iGsQPW VOE9hZLcX+Dspitu2VzM03H2SUk1mA680ZF+xZQogomCEfWJyJWWKoGjjVvUzNcdcF2w AObg== X-Forwarded-Encrypted: i=1; AJvYcCVplRxO8450VyJtE5lnbDmx9ZKLPdX4t3JT9B0DylIVMCmf2e0y4T+Lm8uR2cEAniSArpHCHdamy77cFJ3Q@lists.postgresql.org X-Gm-Message-State: AOJu0YyEBCHhsY2ekUH0TDmB6zIfuv5K6GYkXkDMOGd2YnggIHZHLE4V DqR6z8zaVW7QbTVQwvJDsk9dq62VSpDsm1iAcsAureBt/KEOYK71/uICrIpjGbeW8p1akY/shdE ZFyWvGM3RTJIr7I0e1O6/BnxlsL/aAM8= X-Gm-Gg: AZuq6aL1Xt+UOi+qsKZ+89hkPNWPvW/4+DrG9+ysQHIgZ8Z8oXDoXK2jucKxIywEATU JSgw4xO7taphTJ+CO8yCUDOf34WoEYoH+biOpKSrdqsGuSHuvhFO21juKCfP3VmbFjMHspGRp++ fgrZuWeybhKY2GzJqKuJsycbs/AdO3p74CHKhxuGElhj+Znu/6OkO4BVy2UUClp7im0m0o7RrZV 40+gbMmu4kb12XgSmLEaVVvcoOudDDYxmCxfaVTW+VZh8S2pVPA+eGA8GBr3luAUNVFzxEYnZ87 rJHCpWXD4OM6RLMDLD2n4P3CFB4uq4MCqYut6txZetq+37nry27n91WvYXmlgjIHNCrgw3L2Deo LZFGv8J8= X-Received: by 2002:a17:90b:2dcc:b0:34e:6e7d:7e73 with SMTP id 98e67ed59e1d1-35429ac7edfmr1462608a91.11.1769666874167; Wed, 28 Jan 2026 22:07:54 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: shveta malik Date: Thu, 29 Jan 2026 11:37:42 +0530 X-Gm-Features: AZwV_QjZF7c7hL3qJHU1tbrsV0kGE_-zaFdcz27CdLUTh45_3kWOys58F-YFAsQ Message-ID: Subject: Re: Proposal: Conflict log history table for Logical Replication To: Dilip Kumar Cc: Peter Smith , vignesh C , Amit Kapila , Masahiko Sawada , Bharath Rupireddy , PostgreSQL Hackers , shveta malik Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Few comments on 0003: 1) Section '29.2. Subscription' has this: ~~ Conflicts that occur during replication are, by default, logged as plain text in the server log, which can make automated monitoring and analysis difficult. The CREATE SUBSCRIPTION command provides the conflict_log_destination option to record detailed conflict information in a structured, queryable format. When this parameter is set to table or all, the system automatically manages a dedicated conflict log table, which is created and dropped along with the subscription. This significantly improves post-mortem analysis and operational visibility of the replication setup. ~~ This new section begins by discussing log-destination without providing much background on conflicts, which makes it feel somewhat out of place. It could be made more general by first referring the reader to the 'Conflicts' page. How about this: Conflicts can occur during logical replication when changes from the publisher cannot be applied on the subscriber, for example due to constraint violations or concurrent data modifications. An overview of possible conflict types is provided in Section 29.4, Logical Replication Conflicts. By default, conflict information is written to the server log. The CREATE SUBSCRIPTION command provides the conflict_log_destination parameter, which allows conflict details to be recorded in a dedicated table, making post-mortem analysis and operational monitoring easier. 2) '29.8. Conflicts' section has this: ~~ Note that there are other conflict scenarios, such as exclusion constraint violations. Currently, we do not provide additional details for them in the log. The conflict_log_destination parameter can automatically creates a dedicated conflict log table. This table is created in the dedicated pg_conflict namespace. The name of the conflict log table is pg_conflict_. The predefined schema of this table is detailed in Table 29.3. ~~ This phrasing feels somewhat abrupt and lacks context. A clearer version could be: By default, conflict information is written to the server log. The CREATE SUBSCRIPTION command also provides the conflict_log_destination parameter to record detailed conflict information in a structured, queryable format. When this parameter is set to table or all, the system automatically manages a dedicated conflict log table, which is created and dropped along with the subscription. The table is created in the pg_conflict schema and is named pg_conflict_. The schema of this table is described in Table 29.3. 3) 'Restrictions' section has this: Conflict log tables (see conflict_log_destination parameter) are never published, even when using FOR ALL TABLES in a publication. We shall also mention the restriction of publishing 'for tables in schema pg_conflict'. thanks Shveta