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 1wStR6-000B78-0z for pgsql-hackers@arkaria.postgresql.org; Fri, 29 May 2026 09:23:24 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wStR3-00286Q-1g for pgsql-hackers@arkaria.postgresql.org; Fri, 29 May 2026 09:23:21 +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.96) (envelope-from ) id 1wStR3-00286I-0J for pgsql-hackers@lists.postgresql.org; Fri, 29 May 2026 09:23:21 +0000 Received: from mail-lf1-x12b.google.com ([2a00:1450:4864:20::12b]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wStR0-000000006BK-3zxD for pgsql-hackers@lists.postgresql.org; Fri, 29 May 2026 09:23:20 +0000 Received: by mail-lf1-x12b.google.com with SMTP id 2adb3069b0e04-5a8cb92f26aso14931162e87.1 for ; Fri, 29 May 2026 02:23:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1780046598; cv=none; d=google.com; s=arc-20240605; b=ahY49aLd2YFatFT6721MikYIBMRnNPUfOm9A8esPKXXvKDNRPO22d5p4QPwTDcBvLz R/ks9NAdwFdffctYz8C7LjHUFKg3pbZaGX2Zandep+iQaZ1xX7xQDKjY/sOjqnEz6jzJ mS7MZmneavmX4hFJNeuhmQQDSn1OVo45f7GHrpJh8sy7MOFjrXHsOpem7ioU8YuSR7ga OwhXpbofUxP+7h5s+Ny2T5exXOhmcFPs3jB7XTV3rz+vvouppi+oRnkO/z2ZzPJ35DF9 /GH0SrLdaJDAitXPfCt0pO8IibgL7LnFUU0yKzOZmoaVfNdhOuFXbV72EL2NH0fPiue0 Gr3A== 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=KPbxLFF5oZFq9zRC+24AJJeZmuQMtJstzhQzLKlLx5Q=; fh=8zeHiHwgAmLdV6/UX680xFQiP0y6U47j3WK7Av/Igwg=; b=Ba+Ne3sr6SbBJFxLRFqX20s+3FQtS/Sj47q42GvEb58qtftGY5q3QE+5EpkhM25jKD wiZV0D3QMnSQoJfi9plKeaQLRiyilk4C6RI7DaW18hNh78NugOFxTT7a4wjiAN5z3oal 71s+sUdk0UAbQKxG/CaMK/9MAWhBlYGtSEa3ZFYp+gGwnRvYpdA5pxBOO0eZYazKv4ls 6SY+I03rGQlsfTOThYhIk7gSCgfnUD/76AXyZp7agE1QNHqAufQT3cUaqGYgv7L3vhOA yWrqmw2z36p7HNPl/zCMvqsfKmIEu4c9DMzvx9GmKdoktO4cjhS6QPFDfrLEUKAMQy+P ItAQ==; 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=1780046598; x=1780651398; 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=KPbxLFF5oZFq9zRC+24AJJeZmuQMtJstzhQzLKlLx5Q=; b=E+zSRluKI5j+2NGyUjRAml8FetPyi/pi+Skmu+9yTwOU0f8fnERf404eqRbEvOPCxL aCvU1gUPxezh+xJ/Y7mZCSCGT5GtZDGmy17LCq1rXtZggrgdHRjq6T1bhS2dojZOb1Xn M7hcHu5QiArZKAUtxKh0r7wUegwnGsNB+Yi3uRd/hfl1GuCKH9b7trq8M+WUG1+QPgdc xLFRWeG9ps8q5IBVc9DF0svDImvj5v7dHXjhoyCkKlAF8ndFuTSoaS5i5yCOFpJmwbb2 9czDJQ4OM6ukH6C09KzLx6K1sOFk0qRqKSeiVlYWMYNG8KV+dAH/FopDXReaQKqF0ys6 mtEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780046598; x=1780651398; 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=KPbxLFF5oZFq9zRC+24AJJeZmuQMtJstzhQzLKlLx5Q=; b=f/BbpCQgueHeQcTP28EpBXo70Vuf32FxqFDVdXqSGOlBqbvkxETbDWk0egvpLQb6wn v8ON8Eg/hYsO2trLbtH1HEJeIms9AT6pEU04Q0oQ9uDg2p1W1BB/3E302pR25P83hsJr 51fyR6VYEqU+AJoZLblhy9PKfAjF05X14po8r/MkIBhieYSVMwqdutd4Q10+gd0a0Y5l IqtEOnJUBzOrXs9FL9hZdygmvjS6IwBhCwDPEJMbPqk1p6BfPpMhSvzuWqHfWGJjCtQg YS1Sj0+zTn03cG1V6dTNEdOiGGmzTjL0S2tLyUXkHY9/+mL3S5r7NvM59Fs+Dh61ZToq qpKQ== X-Forwarded-Encrypted: i=1; AFNElJ/BU+p3ocTnxWwuvJ4kiUr4nbFG6BYCUV8SOWWcY9khLXwRPbsuK2MZUl2eM+B2MXHU9ZeBNs6J+rzPTDa5@lists.postgresql.org X-Gm-Message-State: AOJu0Yw14K7Qte4qqBfcI1OVyHnc27G65KyawtlqLunah/utcG8R5B7U 8E8Id3KyO7Jl+DERaQ2fso3HDzg6f/BwV54TZTnB5Yee8K0Yn/C6y/tAZjdFl5gELA3aRVpCPoL pbYQKNmy8QRGPLp3KRuA/A6yg8LJ9ukw= X-Gm-Gg: Acq92OFuyEOeALo8S5czVNqMJtvos+57+Lx6dKaWF93Cxn8enV7GHgOD6Wn54wJ3n5y LrWnQ8UQ1ivxa+IPMmkMoo2fxOytT64mhKH+RI2tV72nchMkGgEywsuZxoEVFnQkZK/y6EmKUpo NwGyz1nPUwYnIrFYZH5KxSx0CVgQT9YP0tyf/roU7dKxiWYL8/3FmaviOkQB/pxWhHgIKATGXvF gM1VZiPE6LZ1Kc2r7QqQKY6hIVut9oiwl3HbvmB0jRPo60c7ndUfELpTlig1n49mGQqogxqblJD kSR+ZUTV/g1LI8Y30sE= X-Received: by 2002:a05:6512:1088:b0:5a8:8df8:1dca with SMTP id 2adb3069b0e04-5aa594b05bemr539798e87.29.1780046597537; Fri, 29 May 2026 02:23:17 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dilip Kumar Date: Fri, 29 May 2026 14:52:58 +0530 X-Gm-Features: AVHnY4Jl2f7VHsMWeAe8iCWAJUma_Dr0I3nqs2NT7CMVE7T_pgQVXGW1fYpH8l4 Message-ID: Subject: Re: Proposal: Conflict log history table for Logical Replication To: Amit Kapila Cc: vignesh C , shveta malik , Nisha Moond , Peter Smith , Masahiko Sawada , Bharath Rupireddy , PostgreSQL Hackers , shveta malik 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 Thu, May 28, 2026 at 2:57=E2=80=AFAM Amit Kapila wrote: > > On Wed, May 27, 2026 at 1:34=E2=80=AFAM vignesh C w= rote: > > > > On Tue, 26 May 2026 at 15:08, shveta malik wro= te: > > > > > > On Mon, May 25, 2026 at 10:13=E2=80=AFAM vignesh C wrote: > > > > > > > > > > > > Thanks for the comments, the attached v39 version patch has the > > > > changes for the same. > > > > > > > > > > I have not yet looked at v40, but please find a few ocmments on > > > v39-0001 and 0002 merged together. > > > 4) > > > Do we need to have CommandCounterIncrement() after > > > heap_create_with_catalog() in create_conflict_log_table()? I think > > > even if we are not doing any table_open etc for CLT in same > > > transaction, we should call CommandCounterIncrement() (to be > > > consistent with other such calls of heap_create_with_catalog and to > > > make it future proof). Thoughts? > > > > I felt this is not required as we are not doing a table open on the > > newly created table. > > > > Okay, command counter increment would be required here if we further > access that relation in the same command. I think CommandCounterIncrement() is called wherever we need to open the relation in the same command. In this particular case we do not need to open the conflict log table so we do not need to call CCI I think I am facing a > related problem w.r.t newly created subscription. After applying first > six patches, the create subscription fails as follows: > postgres=3D# create subscription sub1 connection 'dbname=3Dpostgres' > publication pub1 with (conflict_log_destination=3D'all'); > ERROR: dependent subscription was concurrently dropped > > I debugged and found that we get the above ERROR when we are trying to > find the subscription which is not yet created. In this case, it seems > to be happening because we are using a subscription that is yet not > created for dependency recording. This raises a question as to why are > we creating the conflict_log_table before subscription, at least this > needs some comments. This error occurs because in the commit below [1], we disallowed recording a dependency on an object that does not exist. Therefore, we now need to record the dependency after the subscription is created. And we create CLT before so that we can add the conflict log relid in pg_subscription without an additional update, I will add a comment explaining this. [1] commit 2fbb21170e9053720c2c374b21eb650a22b8aaea Author: Heikki Linnakangas Date: Wed May 27 18:35:58 2026 +0300 Avoid orphaned objects dependencies --=20 Regards, Dilip Kumar Google