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 1viBd2-0008Zn-36 for pgsql-hackers@arkaria.postgresql.org; Tue, 20 Jan 2026 13:18:41 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1viBd1-001GFS-13 for pgsql-hackers@arkaria.postgresql.org; Tue, 20 Jan 2026 13:18:39 +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 1viBd0-001GFK-34 for pgsql-hackers@lists.postgresql.org; Tue, 20 Jan 2026 13:18:39 +0000 Received: from mail-yx1-xb132.google.com ([2607:f8b0:4864:20::b132]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1viBcy-001WoG-33 for pgsql-hackers@lists.postgresql.org; Tue, 20 Jan 2026 13:18:39 +0000 Received: by mail-yx1-xb132.google.com with SMTP id 956f58d0204a3-6442e2dd8bbso4260765d50.0 for ; Tue, 20 Jan 2026 05:18:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1768915115; cv=none; d=google.com; s=arc-20240605; b=EEkT+adYMp3diR3aT5T9SsotXw0uviFgaHmihHxATVXZ8J6SJlYMnRxpPVAg7EVpW2 jZ9fpKGATderKyWLEtESbyCR4lcFB7chELhTsQeVJMgJqetXs9Y4KPq3z52mp9Ojdv2E 16cB5J0yAlJPnPbRkgjd1P0nsxWyrIho73bYAKmswePTGMDiICj+HswhMtPdQrgnA3Ui rGCxgFvGtGQZt4ywIt3v0AHgMnM14iCAqZrK+wYh6dxy7AW0bFWjttGewY83PUYbmr3r f2+8kG5gc/frw8zMsS4ytKqq3PLZl50PhT/I/QHd9volz1+ZPhQfFaM5K41VvfB5OMl1 qOYg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=2nI6OiI25XUbPY9MhJ1kHYuHM1YDyjKj990nSR6J7Pg=; fh=pXhPizp4dTPNSQSS8NuyOZN18j5C/GmbwxpOXAjiKF4=; b=d78uRCWmtB2fTkYtlJuIBsKwdmXFDkIk2/qkn7jYoEptf53+HBHVTJxAC+3qQ0SpEM UKmiIkAk2sFV31o7/bHjFNtHlGVJ9yB2UOBwP2+nVZKAEk+DZSSgL8qL/wsltaHFguQn HbaeWIkFOzZ9vTULgDgQ6kcwDaLwndYJfOhx7jrYKf9Ma5VUrSmtRxJQXwdnPTZaERSV XGkPrrfdPPpCT2pEx0AtKx3l5Bu0+WMnDAtt3CBBFZ+/I8DmsZ9LOA28/Sk9N7bmXoBG vUWO8xQBPeSPxN4d0B28CpPZTl5H3j1B/r1aDCMj17xrI+n8P/XPyrIBXFRQoK+XUg9L KE4g==; 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=1768915115; x=1769519915; darn=lists.postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=2nI6OiI25XUbPY9MhJ1kHYuHM1YDyjKj990nSR6J7Pg=; b=Vtdgw7LD5jHaXwUfZS8ENWvUC6kkAPhf8UmySgnyW4Cb6+svzLhRYxRXzar+EhKID2 wXXC1WJ0WMsyyivUW61RHbBOrh59tz6A36oVQpW5XT3vpdpR8jZMspLf56DdPdg8ZKO8 geZuv3sW2a8hsJdcdXDGBe1+Ba4SdkK63y7a6mUS9/9lN7ClrNVJCy5HO8rFQKtVERbS 5QUAIbDQkhp7PRLIFVPpBeQhw9zUoVeiM62GHqg2m5ndup4i1Na8ShniNhFVZlxU1KW4 uWbsEQeIqbWOBQ+Skdqf4PZ/jOZDCR9lY/F4aEc5zg5fT7wBeYdY1m2fjADoZWxabniN 0Mcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768915115; x=1769519915; h=content-transfer-encoding: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=2nI6OiI25XUbPY9MhJ1kHYuHM1YDyjKj990nSR6J7Pg=; b=kx/JZJ3tihgnj3asPVMyvkz6s1UFt3qRzYPb2PkVcXfNPg05N8NN3dU3tvKGw/DihF NxPh2afK/EF7esOwfpO1xqL1STpWY/SD3Ix+s3NQOZI7A05T4ItXk5kHKoU+R+3wlKnM GOA+d+4JP2WDUTr2Q/hFqNHAwPVd+4/8JX5j18XVzdtEjjSwXpfR7njvF9tvJod9Uxv9 8RrU0En7q+5D7ZxBNtX3vvXg1+/iV8I3gv4B5kzx27zZYQq2svOaK1PRPD/qW4t8aAXy LMy0XI20W1e9FXNORllxozN+d9BEQeP6HhGEfG3d08+UTaL2GRGwuw/30x2HFVF0TJ9X 3fTA== X-Forwarded-Encrypted: i=1; AJvYcCVYG928zxujU14klq7d2e0J+KrEmlnkersSeDk2dAmx6c1ORpAIKQ5htLm5cRbEFmf/cgDFWye/Hmt5r+Us@lists.postgresql.org X-Gm-Message-State: AOJu0YyKWBfSjP9J/O8fI++vVIim2LSA9bknGfa59NzG9TuqCYntkvw4 QY/fU5GKiWCVeMkkPHSvqItiPO7iLsq0VGmreHZyOP5gl9O4nHeNb8Ci7mLdPiqPo22oV6ZN7pf Pvp55hOb+kExepxsljPpKXkHT6ZdkYko= X-Gm-Gg: AZuq6aLg9MHIB6cTdxH/HN4UXCHZ0zGOEw9lSdVHHkNCdhDCK45aHlGGJ6ZJlP8hiWw E5SIgrBpLRIkKmB2OBx3EgO5VV8wLW5MGMARjDCSTeilhEBn5V/5l862bryQlvodn+SySMuUOB6 2W/XQ0aJklCWIfhqN/CXCJ05EoqyZR1uudgs/jdLV1SnhOUExOWOCDq2E7rUsNNG1qqthSVOFX7 JBpt/dweZmckDgLb/iWNn/QHFdftfa0HdR4L2LZobbPM+aihfnMgbC1AfH/AEiFbTomnXz1k2bI mX6hOJ2Uczkog348aTJJifmaHxnBEQ== X-Received: by 2002:a05:690e:1697:b0:649:3bd8:22a2 with SMTP id 956f58d0204a3-6493bd82455mr1471464d50.19.1768915115227; Tue, 20 Jan 2026 05:18:35 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: vignesh C Date: Tue, 20 Jan 2026 18:48:22 +0530 X-Gm-Features: AZwV_QhwtwXn98LeudTrMMYaV5bHm9y9HsVYs8vv31BEZLxGAn4YYOJj2R8K-rs Message-ID: Subject: Re: Proposal: Conflict log history table for Logical Replication To: Dilip Kumar Cc: Peter Smith , Amit Kapila , shveta malik , Masahiko Sawada , Bharath Rupireddy , PostgreSQL Hackers 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 Mon, 19 Jan 2026 at 10:57, Dilip Kumar wrote: > > On Mon, Jan 19, 2026 at 9:42=E2=80=AFAM Peter Smith wrote: > > > > Some review comments for v22-0003. > > > > =3D=3D=3D=3D=3D=3D > > > > 1. > > It looks like none of my previous v20-0003 review comments [1] have > > been addressed. Maybe accidentally overlooked? > > > > =3D=3D=3D=3D=3D=3D > > > > 2. > > + > > + > > + The internal conflict logging table is strictly tied to > > the lifecycle of the > > + subscription or the > > conflict_log_destination setting. If > > + the subscription is dropped, or if the destination is chang= ed to > > + log, the table and all its recorded > > conflict data are > > + permanently deleted. To perform a > > post-mortem analysis > > + after removing a subscription, users must manually back up > > or rename the > > + conflict table before the deletion occurs. > > + > > + > > > > 2a. > > Let's consistently call this the "Conflict log table", same as > > everywhere else, not "logging table". > > > > ~ > > > > 2b. > > This is only a caution for the CLT, so I felt it's better to put this > > in the scope of the 'table' param value. > > > > ~~~ > > > > 3. > > + analysis of conflicts. This table is automatically > > dropped when the > > + subscription is removed. > > > > If you move the to this scope, as suggested above in #2b, > > then you can remove the sentence "This table is automatically dropped > > when the subscription is removed", because that is duplicate > > information you already wrote in the caution. > > The attached patch fixes above comments and other comments reported in > v22-0001 and v22-0002 The tests are failing randomly at the following places +# Wait for the conflict to be logged in the CLT +my $log_check =3D $node_subscriber->poll_query_until( + 'postgres', + "SELECT count(*) > 0 FROM $clt;" +); + +my $conflict_check =3D $node_subscriber->safe_psql('postgres', + "SELECT count(*) FROM $clt WHERE conflict_type =3D 'multiple_unique_conflicts';"); +is($conflict_check, 1, 'Verified multiple_unique_conflicts logged into conflict log table'); +# Wait for the conflict to be logged in the CLT +$log_check =3D $node_subscriber->poll_query_until( + 'postgres', + "SELECT count(*) > 0 FROM $clt;" +); + +$conflict_check =3D $node_subscriber->safe_psql('postgres', + "SELECT count(*) FROM $clt WHERE conflict_type =3D 'multiple_unique_conflicts';"); +is($conflict_check, 1, 'Verified multiple_unique_conflicts logged into conflict log table'); In both places it fails because the number of conflict records inserted can be more than 1 like below: [18:35:58.342](1.786s) not ok 1 - Verified multiple_unique_conflicts logged into conflict log table [18:35:58.346](0.004s) [18:35:58.347](0.002s) # Failed test 'Verified multiple_unique_conflicts logged into conflict log table' # at t/035_conflicts.pl line 104. [18:35:58.348](0.000s) # got: '2' # expected: '1' How about we check that the record count >=3D 1 and check for 't'. Regards, Vignesh