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 1ve2k8-008DT8-1e for pgsql-hackers@arkaria.postgresql.org; Fri, 09 Jan 2026 03:00:53 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1ve2k7-005Tsw-1I for pgsql-hackers@arkaria.postgresql.org; Fri, 09 Jan 2026 03:00:52 +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 1ve2k7-005Tso-0E for pgsql-hackers@lists.postgresql.org; Fri, 09 Jan 2026 03:00:51 +0000 Received: from mail-qt1-x82b.google.com ([2607:f8b0:4864:20::82b]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1ve2k5-005Oil-1x for pgsql-hackers@lists.postgresql.org; Fri, 09 Jan 2026 03:00:51 +0000 Received: by mail-qt1-x82b.google.com with SMTP id d75a77b69052e-4f822b2df7aso50595791cf.2 for ; Thu, 08 Jan 2026 19:00:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767927648; x=1768532448; 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=whnPXUoYpJNBD1xF6V7w6yKAQFrX8eB4KupZeg/5IGg=; b=TQsUgZMUNWpJQaQtcIzZgkLvRawHEKqqrj5wTCQ0mkNXA5nJ5oVJaoXH01oH8guiK0 wNf/H82vqKXismOSVFmI+ELkGatClVwHjTNuevqLM3Q0qYkPRuOucYLnnoR+CZsLAffl 36FLey4TPfFjMHc+MtaV+G2/EzL734wwd/QP1SlY3lVE0o+efZh3m0y3TsKUCTfXsyec qG5wfqzUcVhp2wNgj6HpasVRNsvTQsH1xTH7FTvvsmsl0JPQakbyNHhbrFly3DYN0xE1 dQc/ubOvMH4WCkpIxO3vnpoL6KDQK92a7+Jj9qElfr/UztyER8ay6b0YovxDiwuV0iou 15tQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767927648; x=1768532448; 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=whnPXUoYpJNBD1xF6V7w6yKAQFrX8eB4KupZeg/5IGg=; b=oxJyXoPj5cDIfH8X3lMo9wVA+He5/ZEE5z3W2nyzEe9z8vmDkeFesVoe1uT9mxe6Mb GyF06hX3X8ccN4F7rXSeKQPLx/JLOq0jshTuAdE7Dijwk5Ic2Ns57ndPaglxvdyVcFqs m4hjE2+BVIWJe4XxzTbwFXhbaAEUeP8KCNvJUKN1OLwT8Ek54OeFYyQ3ORm/VnnlPDQB p+yR9XjNnPDnP+erTSyVeXybXyE8Jwb4hAi2Zv6JbnKsC+Njjzy4mcrnrCzIrQPLk3Jb tzkethKtziqtceKgYwpSYMcPkVYzQTwDZ2RTlSKIMiOr+I64Yt/GXrinuN+c0S7Pzqq/ vpyg== X-Forwarded-Encrypted: i=1; AJvYcCWcoY44GcmXpby9QJXqK5kAXwXSISle5VkMZm9ZDwjbtUIUdQLsHzd2YXO/OXvN4Bm7QJdb2wcEoNExtuPS@lists.postgresql.org X-Gm-Message-State: AOJu0YxU4zgyf8fC1ITPytrmtpnPJkt/NNI7+AcijxZuQ6nv3hrxi9tg 0yjH4y1K3Cwc6+0PIseLUEN6lOjr9hNdeVbs7jAUDoGJUswUVSBQfw0YQIEzL8muXU9NyQ7Wb0s 8iDrxzuCpDdnoP9iZ+8mqJzEbxijgwr4= X-Gm-Gg: AY/fxX5ZrPyWZNpLsHptVRHYEu38+Pd9DHW9qwwSGR7FTvL3RG9B7Gu6iFBiHrq16Gc ce0nUUsJJmmnmCUwbSlwFFopYHHMkyuLUeL0gXdTHg5PI9DT/VMaMeynjsOS0fkBX7EaaO+yWYm p8I+ExYrwDmnG9Jlzdt7VjtfOXxtKShLPSrJtX5FCJ+S1tGzH7vs/1if6ASBWTj1QAn4yTMKWxc vvk7kLATo3mgYG3AMd05yBFY6q0CmsDp/My2RsCcqpsH1XZaqSWJLY3VMxQ0sCwTxEwtHqXVEKC 8+IzBkYDj4E26bgvWUdol1b+fiu4MXu9zbhE X-Google-Smtp-Source: AGHT+IEf2qQy8kgjpdMC+/jKvu3EQm/kNR+ElXtqjqGo0UWYgXN+Pq2YBA9/QqcS2E0LMzRA5Mai2JyR0Fd6Q9/2HvI= X-Received: by 2002:ac8:58c8:0:b0:4ed:6e15:d2cc with SMTP id d75a77b69052e-4ffb49f7098mr115406041cf.54.1767927648185; Thu, 08 Jan 2026 19:00:48 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Peter Smith Date: Fri, 9 Jan 2026 14:00:20 +1100 X-Gm-Features: AQt7F2pyHjMRxubOosgUW_2SCiltIDUEXv5NOA3Vr1t1TPQm1AUkv_P2fqAtlfA Message-ID: Subject: Re: Proposal: Conflict log history table for Logical Replication To: vignesh C Cc: shveta malik , Dilip Kumar , Amit Kapila , Masahiko Sawada , Bharath Rupireddy , PostgreSQL Hackers Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi Dilip. Here are some review comments for the v19-0002 (code only, not tests). ====== src/backend/replication/logical/conflict.c 1. +/* Schema for the elements within the 'local_conflicts' JSON array */ +static const ConflictLogColumnDef LocalConflictSchema[] = +{ + { .attname = "xid", .atttypid = XIDOID }, + { .attname = "commit_ts", .atttypid = TIMESTAMPTZOID }, + { .attname = "origin", .atttypid = TEXTOID }, + { .attname = "key", .atttypid = JSONOID }, + { .attname = "tuple", .atttypid = 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) ~~~ 2. + +#define MAX_LOCAL_CONFLICT_INFO_ATTRS \ + (sizeof(LocalConflictSchema) / sizeof(LocalConflictSchema[0])) + how about: #define MAX_LOCAL_CONFLICT_INFO_ATTRS lengthof(LocalConflictSchema) ~~~ ReportApplyConflict: 3. + /* Insert to table if destination is 'table' or 'all' */ + if ((dest & CONFLICT_LOG_DEST_TABLE) != 0) I think it is unnecessary to even mention 'all'. The bitmasks tell everything you need to know. SUGGESTION Insert to table if requested. ~ 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. ~~~ GetConflictLogTableInfo: 5. + *log_dest = GetLogDestination(MySubscription->conflictlogdest); + conflictlogrelid = MySubscription->conflictlogrelid; + + /* If destination is 'log' only, no table to open. */ + if (*log_dest == 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) == 0) return NULL; ~~~ build_conflict_tupledesc: 6. +static TupleDesc +build_conflict_tupledesc(void) +{ Missing function comment. There used to be one (??). ~~~ build_local_conflicts_json_array: 7. + json_datum_array = (Datum *) palloc(num_conflicts * sizeof(Datum)); + json_null_array = (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? ====== 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. ====== Kind Regards, Peter Smith. Fujitsu Australia