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 1veSna-00DgKs-1w for pgsql-hackers@arkaria.postgresql.org; Sat, 10 Jan 2026 06:50:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1veSnW-009ciB-1V for pgsql-hackers@arkaria.postgresql.org; Sat, 10 Jan 2026 06:50:07 +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 1veSnW-009ci3-05 for pgsql-hackers@lists.postgresql.org; Sat, 10 Jan 2026 06:50:06 +0000 Received: from mail-lj1-x22a.google.com ([2a00:1450:4864:20::22a]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1veSnV-005CGE-0r for pgsql-hackers@lists.postgresql.org; Sat, 10 Jan 2026 06:50:05 +0000 Received: by mail-lj1-x22a.google.com with SMTP id 38308e7fff4ca-38320cd563aso14542591fa.0 for ; Fri, 09 Jan 2026 22:50:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768027803; x=1768632603; 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=T4ouUFylJNBVb1MN3Mc3p59aIHF+Gt+03wORGIA66Lo=; b=OQO3w5wjZ3bXK6MPpSN5808MNDYCWa5g2XG+BTtKUkX+iZtueN2gjDZL6LYwKvTbff q6H3cF5TWS4Ir3EM0f7EHojqwN4m7lZwf9B7D5TecGkuNtpmcAeWxVDt2Hrrhxoc17Vw wWwYV149OWh9mQ1u1MXaveHFEgEoA12TqRwHZhrzb6/Ba6T0BuH0YSt7wr7Je6rvTT3k Qsi/uFgx/XWEP886O7MX04vr43uPeM84/NbGuxBpmHjqJurgVzlqyZJIbW+M9Pg/Lc35 ddh+gaD5wFgpWjEA9NN82guiPIbmxjKD4oFUna/AEmBDMVmIFE3bZVn+SljS+TayEvFx H4aA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768027803; x=1768632603; 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=T4ouUFylJNBVb1MN3Mc3p59aIHF+Gt+03wORGIA66Lo=; b=CNQ/GTFuxef1h3z3S95lbgWRRF7JVDvwy6RuM03lozLFo8EPG6ZTLuO4VY85zVDsNC +hdgfJITt9xMiin/LTWa3q1MkYEuvD+5CXkOYn6wr4kosklrf68jXNMEmqDVBu8BNXW0 n7rtkogQJDP0lAwRkepQoU9cNbHem+AaYricOFQAV0kvD3hRPj2LCeZc8q6TsyD4zSpM BZDzJ4qDB5eMQBUC7q1N0g1qtvOQShGS1+ir41VwFoZQ+eeud/h3AEROqRF5IbzqA01i vpsDX6tMV2Xa1gmnKMChJlpX/1k5Cnae4DjcgtrYdedtgKkH2j1JPhKz6BnxNeLJv7rO A+eQ== X-Forwarded-Encrypted: i=1; AJvYcCVJ+X4BKHYRxUiSyFRf4OxziMhUOppI15JdX1izGSGZQ4M5/EU+rjIb31qUFqu7U/e9WvULJC9RyDc6V5gq@lists.postgresql.org X-Gm-Message-State: AOJu0YxxNta8jXWBVY0OdfURdcv+7UcqaeKXQW9Fkeg3nAT6PHLnBJJ4 C//NJ5DIJD8Tn/SveS+uVX9bB/hgsJUCVwvqW216TTTXOFZLqtQ1AnuDniGTyV2BLbgGbx/zme2 AP4nZMeFBMJpNqnDnokx/T/h5xuP/0C0= X-Gm-Gg: AY/fxX6pbDGlRxyorPdM1vYTa4WfiuCJKcLsk6t0XVkgkS26/Qg261+Y7wgLZEV6Ycx hvPjRPQI50NcXGZ1RtGC4leY68/MGMm/hj89z4bz97XSU+YKznAejmgahu4eEudAknD6J6wOle0 EXsj5uMSSh2N9tHxEI61V8rZdeKe6lGNDPZoU7h9s0N2gwX7Q7nVz45Xe+KMJ0L5OdmpLePXaUp 89S47f6bi/gYKP7ZKUF5CkdlbL4QPeHK2Q6P8CK19VMiVU0blkeKl37R9dImBxWvh4qmbs= X-Google-Smtp-Source: AGHT+IFaNNP4xPkwiOnCheDNDT179/Z2BM0SiN6El9MJNRD+pKXtjuB3exyOnx5AZXz6oRRJaFfez/1p45yu3A3diCs= X-Received: by 2002:a05:651c:1545:b0:37a:47a4:d5cb with SMTP id 38308e7fff4ca-382ff681449mr37261721fa.11.1768027802965; Fri, 09 Jan 2026 22:50:02 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dilip Kumar Date: Sat, 10 Jan 2026 12:19:46 +0530 X-Gm-Features: AZwV_QihZ7awetLNV80l1diz5SoEQx38Pb-qrgcsqFmW3RRj0tIt0WE_8vYXVgw Message-ID: Subject: Re: Proposal: Conflict log history table for Logical Replication To: Peter Smith Cc: vignesh C , shveta malik , Amit Kapila , 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 Fri, Jan 9, 2026 at 8:30=E2=80=AFAM Peter Smith = wrote: > > Hi Dilip. > > Here are some review comments for the v19-0002 (code only, not tests). > > =3D=3D=3D=3D=3D=3D > src/backend/replication/logical/conflict.c > > 1. > +/* Schema for the elements within the 'local_conflicts' JSON array */ > +static const ConflictLogColumnDef LocalConflictSchema[] =3D > +{ > + { .attname =3D "xid", .atttypid =3D XIDOID }, > + { .attname =3D "commit_ts", .atttypid =3D TIMESTAMPTZOID }, > + { .attname =3D "origin", .atttypid =3D TEXTOID }, > + { .attname =3D "key", .atttypid =3D JSONOID }, > + { .attname =3D "tuple", .atttypid =3D JSONOID } > +}; > > Maybe this only needs to be used in this module, but I still thought > LocalConflictSchema[] (and the MAX_LOCAL_CONFLICT_INFO_ATTRS) belongs > more naturally alongside the other ConflictLogSchema[] (e.g. in > conflict.h) Since this is used only in conflict.c, my personal preference to keep it in the .c file > ~~~ > > 2. > + > +#define MAX_LOCAL_CONFLICT_INFO_ATTRS \ > + (sizeof(LocalConflictSchema) / sizeof(LocalConflictSchema[0])) > + > > how about: > > #define MAX_LOCAL_CONFLICT_INFO_ATTRS lengthof(LocalConflictSchema) Make sense > ~~~ > > ReportApplyConflict: > > 3. > + /* Insert to table if destination is 'table' or 'all' */ > + if ((dest & CONFLICT_LOG_DEST_TABLE) !=3D 0) > > I think it is unnecessary to even mention 'all'. The bitmasks tell > everything you need to know. > > SUGGESTION > Insert to table if requested. Done > ~ > > 4. > There's a slightly convoluted if;if/else with these bitmasks here, but > I think Shveta already suggested the same change as what I was > thinking. So now we have this, which is first handling the table case and handling the LOG case separately, because irrespective of whether we want to insert into the table or not we need to check what we need to log? What's your suggestion for this? if ((dest & CONFLICT_LOG_DEST_TABLE) !=3D 0) { } if ((dest & CONFLICT_LOG_DEST_LOG) !=3D 0) { } else { } > ~~~ > > GetConflictLogTableInfo: > > 5. > + *log_dest =3D GetLogDestination(MySubscription->conflictlogdest); > + conflictlogrelid =3D MySubscription->conflictlogrelid; > + > + /* If destination is 'log' only, no table to open. */ > + if (*log_dest =3D=3D CONFLICT_LOG_DEST_LOG) > + return NULL; > > I think checking and mentioning 'log' here is not future-proof for > when there might be more kinds of destinations. We just want to return > when the user doesn't want a 'table'. Use the bitmasks to do that. > > SUGGESTION > /* Quick exit if a conflict log table was not requested. */ > if ((*logdest & CONFLICT_LOG_DEST_TABLE) =3D=3D 0) > return NULL; Make sense > ~~~ > > build_conflict_tupledesc: > > 6. > +static TupleDesc > +build_conflict_tupledesc(void) > +{ > > Missing function comment. There used to be one (??). Yeah it got lost in some of the refactoring. > ~~~ > > build_local_conflicts_json_array: > > 7. > + json_datum_array =3D (Datum *) palloc(num_conflicts * sizeof(Datum)); > + json_null_array =3D (bool *) palloc0(num_conflicts * sizeof(bool)); > > I may have already asked this same question in a previous review, but > shouldn't these be using those new palloc_array and palloc0_array > macros? Done. > =3D=3D=3D=3D=3D=3D > src/include/replication/conflict.h > > 8. > -/* Define the count using the array size */ > #define MAX_CONFLICT_ATTR_NUM (sizeof(ConflictLogSchema) / > sizeof(ConflictLogSchema[0])) > > This change appears to be in the wrong patch. AFAICT it belonged in 0001. Fixed. Will shared the updated patch after fixing other comments from Shveta as well, thanks for the review. --=20 Regards, Dilip Kumar Google