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 1wPxWO-001AwG-37 for pgsql-hackers@arkaria.postgresql.org; Thu, 21 May 2026 07:08:45 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wPxWM-009RQl-2w for pgsql-hackers@arkaria.postgresql.org; Thu, 21 May 2026 07:08:43 +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 1wPxWM-009RQd-1c for pgsql-hackers@lists.postgresql.org; Thu, 21 May 2026 07:08:43 +0000 Received: from mail-pl1-x634.google.com ([2607:f8b0:4864:20::634]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wPxWL-000000003xR-3ODY for pgsql-hackers@lists.postgresql.org; Thu, 21 May 2026 07:08:42 +0000 Received: by mail-pl1-x634.google.com with SMTP id d9443c01a7336-2bc763e2ba8so27674155ad.3 for ; Thu, 21 May 2026 00:08:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1779347320; cv=none; d=google.com; s=arc-20240605; b=BA175yJ062ppz8t1LLLCwTuXWDFHOse/PeNl3ayQ/Jh9y6PpGe7KEtITY3YKCT1wjF oAWHVfdSefVCw99vVMKY2b/icXcGp/COHSoOvprBt4riM2nyeiA3/6WJ5RLqB/vzwWT0 gmqWlm14ev7JOhPYunb40lHpbtAn0TZ/5i8Jx97xJdqsa/PYFd5+Fspj442qX7YMWwIO UphfwpZdiMZzLdN3chIigkJzKnpS7ImZrbPNhGYDnnMblWwLbXwEoxo9kPyaFsB36IqJ IjuxDL0YeVkpdLRAXSp5DoXXB9Z7nkQNrS2wsmcviRk0TlbS2VPcg7gSmgMIXxIREqLd A9sQ== 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=NLxZG0R52F7VKitPpgmlazxU7iH2SjhfSPMLxnXpXVo=; fh=nYj30YvkTV9Ab3bDNfohylsgCnTCJ52TV+OsWxnZtJc=; b=SxY86m0Pa1kSLj00PB2VYYgeWkw3Naof4APYujOrpvw7AjsIx1BOcUgIAFd/yVXEVn uhmkhUc+AU5TwCD2abJTSFHBnR6ZkdXADA4K760f3IFKTP0VQ0Xlh+ZyqoKOn5jJUytr eBpZr/27FPIoB2msNxYsr7mKtyIHRe4ee5NLWpBM0lkCxBjMPZ7ffuxP0ABpnORGql4y L5WtAPGpgL8ALMLop0Pc8fPuQZVjvzV6cbH+lMJjGvRKoRA7WWKleVgEJBUnafPnt0GM SVzxSBem+3I070GJ5jWNxGejr1r48PN2VBIlcy9c3LwjM9g+xAmRGSr8ukuwmrmqE3KU 0Z8w==; 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=1779347320; x=1779952120; 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=NLxZG0R52F7VKitPpgmlazxU7iH2SjhfSPMLxnXpXVo=; b=quzh550kwi+E6h1nz+A/n7+JR/DyXlyZi5uK3yxrH58k3amOQEQspWAHYvuo/q7WBw f5nMjy0LkLW5b1tUfAVAaukZ6lJjqZVwnJ+/myxjUiUFPJ/kAhiyu3VExwHixp131F4j NGzIgMQF+HRHTt3pplom+IKGKIUEE5hsoTMhkZi8T6T+vqnIQaUxy7fSl8RUaQEqnqrg rPacq5WtRBMkaIWH2vurX4hC0rFALHa9wV9gRkF92lk4VyCtqESOWt7Bx3dRsk1gDY+/ 6+A46OrNE9gjOYfHpjruUhvfOuTdcDSR+uQx7QdX0rc22ZukZIIMJ4OhXo16LQT06GIQ n2VQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779347320; x=1779952120; 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=NLxZG0R52F7VKitPpgmlazxU7iH2SjhfSPMLxnXpXVo=; b=Sl4KClUPxmoGf5lmhbmKyITBf6SYlqNsOYMxHEJ5TGympFCopHcsVgaFMkSVf/foPG FgvRcSfwG2mjdaOfMWmVvY8Tx6zRNpwzAe2ln3FjomFrFSrb+ZE9Vnk0Ey13ziUGZYEM ClVFjROkhilPmEUdtnuAKcc18JpgFCq3Q0TLZnl3tMyfRxH5l19lTI0QMpBvLh5xC5WV dkbkM/cK55mRbqg39aAWtIm+uNRY5P4RsKnjdsP2OPRnZcFlDEltdjmVF+KKnXdGZTBi IS87rpDuZt4DKUZB12GFGnfTNfWuA59MA6wgd5n+DOWvjpFFPrwjGzgDtJdPNP5CMXdp lLwQ== X-Forwarded-Encrypted: i=1; AFNElJ+3zYzu63al4c08F7c876Q9I1Li1xNvyMjOCbITxrJ3q9DxUPbsW9i9pu0TD4lfFFNB0w59ZerUCrmFsSyG@lists.postgresql.org X-Gm-Message-State: AOJu0YwfaecLVb7hd9b+yFTBHUE7/U7E33ma5xUctBuOz9k7XMaBeO82 ADR2abZh/fIi7lxSLWGqOORc2ifULw/kyTM6knVAeM8OJAbJG8FD4J+HNUX7SBXoGXWtQwUXVZ4 9cItsI1Hc9aVkM787tQ3ut6UstGafyi4= X-Gm-Gg: Acq92OGge2GuPE6+d6bZG8hwAhQsXlPYgAb5xUcxAJz33Pux8usGxKuC6b2Ka2zGpd1 1nBTpUCtMkuZCZ/bTUDJE3d3hCLo6nSDOkM956SPHK6H8ronKRcFIJdj0dnKjuc9z70lCF+Xptn VnwD5ZXhcUsWAUBJxb8lGRzJk+J+WU8OX/gnuqGs4F2QdiJWOj08gtObEhE2M2U91p562e7C0La wD52FLgUMMvR+s1TsLdGOZpcUs4NXf3gPZwxX9MxH23OPgmBfyv0nbGH7deYVmJc3ujw4itql5U BSVxEbLHpv5RwfINxm2ctsiPBwE8UiDYmCCw1s7Qq9FhWTEkpQDv4g== X-Received: by 2002:a17:903:2b0b:b0:2bc:db02:d1e6 with SMTP id d9443c01a7336-2bea33932c1mr16495905ad.38.1779347320267; Thu, 21 May 2026 00:08:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: shveta malik Date: Thu, 21 May 2026 12:38:28 +0530 X-Gm-Features: AVHnY4LjRi3C_eCEo0tvL6iur-9bVDhDtAbnW3ZuSRATYm7JLfuKiFp8FwPLT00 Message-ID: Subject: Re: Proposal: Conflict log history table for Logical Replication To: vignesh C Cc: Dilip Kumar , Nisha Moond , Masahiko Sawada , Bharath Rupireddy , PostgreSQL Hackers , Peter Smith , Amit Kapila , 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 A few comments on v36-007: 1) AlterSubscriptionConflictLogDestination + want_table = (logdest == CONFLICT_LOG_DEST_TABLE || + logdest == CONFLICT_LOG_DEST_ALL); + has_oldtable = (old_dest == CONFLICT_LOG_DEST_TABLE || + old_dest == CONFLICT_LOG_DEST_ALL); Shall we replace checks at both places with CONFLICTS_LOGGED_TO_TABLE? 2) I think we can move 'AlterSubscriptionConflictLogDestination' into the configuration patch itself (if needed). It is not directly used anywhere in upgrade flow as such. IIUC, even if upgrade flow uses it, it will only be used through AlterSubscription. 3) AlterSubscriptionConflictLogDestination: + if (want_table && !has_oldtable) + { + char relname[NAMEDATALEN]; + + snprintf(relname, NAMEDATALEN, "pg_conflict_log_for_subid_%u", sub->oid); + + /* + * In upgrade scenarios, the conflict log table already exists. Update + * the catalog to record the association. + */ + relid = get_relname_relid(relname, PG_CONFLICT_NAMESPACE); + if (!OidIsValid(relid)) + relid = create_conflict_log_table(sub->oid, sub->name, sub->owner); So this function will now be used during upgrade where destination is TABLE/ALL as well as regular Alter-Subscription to change destination from LOG to TABLE/ALL. In upgrade case, we expect the relid (CLT) to be present already while in regular case, we don't expect any CLT to be present. The above code does not take care of maintaining the sanity checks. It should be able to distinguish the 2 cases and Assert/Error if the condition is opposed to what we expect. 4) Also , I do not understand how can upgrade ever pass this check: + if (want_table && !has_oldtable) It is not obvious how the upgrade flow will pass this check because theoretically both the old and new setup should have the exact same configuration; i.e. if 'want_table' is true, 'has_oldtable' will be true. We can add a comment to clarify the situation here. thanks Shveta