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 1vbYlu-007Z7c-1x for pgsql-hackers@arkaria.postgresql.org; Fri, 02 Jan 2026 06:36:27 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vbYls-009VnK-0o for pgsql-hackers@arkaria.postgresql.org; Fri, 02 Jan 2026 06:36:25 +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 1vbYlr-009VnC-2e for pgsql-hackers@lists.postgresql.org; Fri, 02 Jan 2026 06:36:24 +0000 Received: from mail-pj1-x102f.google.com ([2607:f8b0:4864:20::102f]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vbYlq-003lw5-2b for pgsql-hackers@lists.postgresql.org; Fri, 02 Jan 2026 06:36:23 +0000 Received: by mail-pj1-x102f.google.com with SMTP id 98e67ed59e1d1-34c27d14559so9280455a91.2 for ; Thu, 01 Jan 2026 22:36:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767335781; x=1767940581; 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=O9CBNINap9lJQfoBuKcS1QCDuUrDN/7INgtAi0A22kU=; b=fmw/JzzAjmGSdVfm/F1QWFIjzAY87s4jcXcJ4+XbwJna6z+XcRiJN9cJcdHxRdzxtn 79wNWEpacudu0G1XHc4yS1iBZhUj6Ppqfm0E9xAmmhlrmuB0DQPyEA8LV0+Fuhk1McWk cXPHvsi1X1twW5O+SiRCEIgqePTlhDRWOKJOqo+iD1DWYZeD4YIImZiftdw5uMuBqJPs FtRfoFI8eFVt778q4f9fijJrkNIR07IPSbsv/tqkoOFR1o6ePxLOXEfe570aPN49GMAL MA/Wjer4VvKHNNDxR8XxjKsSbdgmL/puMHKWean2YK7K1N50RUDsHFlKpLnGakMe85sz mZJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767335781; x=1767940581; 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=O9CBNINap9lJQfoBuKcS1QCDuUrDN/7INgtAi0A22kU=; b=iVzOr2dsiJz/wNwXBJjasZeSh9KcLuqW6pZx5OwE5VZGj7TWNdaIAQe6WyAP5C+goL klvenYChNz7HronEssqKn+uK/KIAoL/jnn6lg3o4zjNwAtd5dXRNlhu3lowTvGs+Yn6j dsRF725sKJIwuBVhb+Wl/MHztfZsZlgoTjJagvv7qeNE+zLzzBep9R4figqA0ULZPB3n J78qLpXcPhBVOBHG9yHLs6qaTs6QCVFApRbocT609LOMpyrXpb6Gh0XD/BiaOZBeMki+ gNfoa47Dv3m3cxPYkNG0vZYQUpMjGUDvRb8e4L4XRUkNf76AlPMHe0XoXxr0DNCoHnj3 HunQ== X-Forwarded-Encrypted: i=1; AJvYcCWK3Zea2bGU97APwefZAGYqWG/BF6rfrKihU6Am6z9KLexvb80G6lXvQRTOTU7wvkjSG2uw8Gw8JLTcNxkM@lists.postgresql.org X-Gm-Message-State: AOJu0YwFfAeG1mhkYSgBjfwLFplCnpZfHd4ksBZfQn9E8/kfw8NmGgAp MzYTtBCTEtmveLg0HtY3tnb3tyYlOAq3DeYwShFq23FnMjgHpnEy7dtyGb53hkR8RP8jJk9HNfN hjksObrv7PU0VdxDvBQEUqpZpQtYCvcw= X-Gm-Gg: AY/fxX5N1O4t67wEzo7T+gB5D3GyzRAPG3V8k7mqG7tBUpXPbMrfy1w/reZVf6wb0YJ H1/QFE0PAlQuK2SUVf1t1kjZoCTKU0x3jW/P/zDaI2En/T8ayNGi2EzuiDKBxBwEMnvwce8SxMd 3JyMMnHL8LnE6Ri9oM6g/X+bhadhN72XPLYdge2PKZ3GVXA2f+Mh3FRGL81IclDsetoIVW7WrTQ lOxM80YiInWlcKlwyM6nLY/OemsIetmAGabf1txxzGEvyVO3V9obix2LZ+aMG4DyyMrEv5V/7NP dQfxfJSHSSnhNBKmP9wzVO065qeexn4nvamrh9cXSU5XVljOe8Le X-Google-Smtp-Source: AGHT+IEmMAzTp5h7zNiMAaYfeq0YGBP02Ezrk9Q2JsOtltAW2QWvR9hKmtZ7yyIbgBFJHhnBNPGmhrO0/hObZbCtpag= X-Received: by 2002:a17:90a:ca90:b0:340:d06d:ea73 with SMTP id 98e67ed59e1d1-34e921af95amr23602654a91.19.1767335781428; Thu, 01 Jan 2026 22:36:21 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: shveta malik Date: Fri, 2 Jan 2026 12:06:09 +0530 X-Gm-Features: AQt7F2pL9zh0rXPDQx1Lbpg7Gbze-SXqSswFPjWXwxygKax0JUHq5x4R1WZZ5SY Message-ID: Subject: Re: Proposal: Conflict log history table for Logical Replication To: vignesh C Cc: Dilip Kumar , Amit Kapila , 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 Fri, Dec 26, 2025 at 8:58=E2=80=AFPM vignesh C wro= te: > > > Here is a rebased version of the remaining patches. > Thank You Vignesh. Please find a few comments on 004: 1) IIUC, SubscriptionConflictrelIndexId is an unique index on sub-oid and conf-relid, but we use it only on relid as key. Why didn't we create it only on 'conf-relid' alone? Using a composite unique index is guaranteed to give unique row only when all keys are used, but for a single key, a unique row is not guaranteed. In our case, it will be a unique row as conflict-relid is not shared, but still as an overall general concept, it may not be. 2) IsConflictLogTable(): + if (OidIsValid(subform->subconflictlogrelid)) Do we need this check? Since we=E2=80=99ve already performed an index acces= s using subconflictlogrelid as the key, isn=E2=80=99t it guaranteed to always= be valid? 3) Please update the commit message to indicate that this patch makes CLT publishable if a publication is explicitly created on it, else few changes become very confusing due to unclear intent. 4) pg_relation_is_publishable(): /* Subscription conflict log tables are not published */ - result =3D is_publishable_class(relid, (Form_pg_class) GETSTRUCT(tuple)) = && - !IsConflictLogTable(relid); Comment should be removed too. 5) We need to remove below comment: * Note: Conflict log tables are not publishable. However, we intentionall= y * skip this check here because this function is called for every change an= d * performing this check during every change publication is costly. To ens= ure * unpublishable entries are ignored without incurring performance overhead= , * tuples inserted into the conflict log table uses the HEAP_INSERT_NO_LOGI= CAL * flag. This allows the decoding layer to bypass these entries automatica= lly. */ bool is_publishable_relation(Relation rel) 6) get_rel_sync_entry: + /* is this relation used for conflict logging? */ + isconflictlogrel =3D IsConflictLogTable(relid); Shall we add a comment indicating the intent of change in this function. Something like: /* * Check whether this is a conflict log table. If so, avoid publishing it v= ia * FOR ALL TABLES or FOR TABLES IN SCHEMA publications, but still allow it * to be published through a publication explicitly created for this table. */ thanks Shveta