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 1vli7D-002n2O-1R for pgsql-hackers@arkaria.postgresql.org; Fri, 30 Jan 2026 06:36:23 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vli7B-003D1W-1k for pgsql-hackers@arkaria.postgresql.org; Fri, 30 Jan 2026 06:36:22 +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 1vli7B-003D1O-0O for pgsql-hackers@lists.postgresql.org; Fri, 30 Jan 2026 06:36:22 +0000 Received: from mail-lj1-x235.google.com ([2a00:1450:4864:20::235]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vli79-00079j-1L for pgsql-hackers@lists.postgresql.org; Fri, 30 Jan 2026 06:36:20 +0000 Received: by mail-lj1-x235.google.com with SMTP id 38308e7fff4ca-385b9be0759so15099721fa.3 for ; Thu, 29 Jan 2026 22:36:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1769754978; cv=none; d=google.com; s=arc-20240605; b=JrpCc0xYQAR4WnTdxHJuVfqe3SdrWPuPF+I74rUr3mnnkhKKlAi30Ood+ewvS3xYFO dw2yQso4L+k5y4/zWuM4JpjWHt4gqLZ8kDjPO2PT148gQTp6dA0rV90FSOLNbD4PHCwN D0yyoatPKbLq1r8XCFd5FQOSMfEJiiTCabN8VXkGP/AuhEL5+tFFxtzOGWIru1GHq++M rHqdkiii4OFi4FyAPYS21Oz3Jwi4KgZ1vVSzOh5V59z8SiA/Vg/MFbn77RD7zwUw+HwR MedNS9bJKoHfQy+3aZUo7l23uwPiWVIxRLOsr13VvhzbeA3FOo3OtTr0g2IUw/JtbZO+ jAEg== 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=Wd1ua9oQn9fAQypNUkPZk/Pg7uXlEBYqtmR2BH2rdoA=; fh=YMbNay6dpI/1gZ22yLdLF/eMyTMltOZhDfN23MOxJZ0=; b=LUboI7lw8ZvOQ1RKPGCtZmysxaa+CgVGyBZsJF/B7ra0VPfge+/ryW2PzHJ35hojJ8 RF354LTA6VhfO70CaINEjW82QHuFV97r3ZSyKvpmCdiAkHovxF3WEkvBN3c2DgO6Ev74 PLt3dNe4CzSX4TojbBcY4u+pwbN8qeMEUjszt/YseOxJYvQ1/86fMlmRymhy1brNIWCZ HlKpTYnULz2Rqpx1zWHj2KpheD/6Gp61VwOP/9unvWVnBYiythyO8hCQ83DJIrEsYOdh fPUuSaqLsodVTFBsTMJvYWBBT9zi8YZNdJO7SFypeHbBZINs3MRqSQsYTPFBsiaj3cd0 ApHQ==; 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=20230601; t=1769754978; x=1770359778; 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=Wd1ua9oQn9fAQypNUkPZk/Pg7uXlEBYqtmR2BH2rdoA=; b=YtaYhtFuNYxJJ2ssTnyMNI0ZYFNDUmqYazHW7mxazcX7fjOslfye+NrJ7LVmF2DyY3 H7RDnB3bJTUFouwHDOP1UHdybxeVoxlgHCAfHdZGQ34l8YPu6T40Fjig6Be/Nt/GZ7Vl 4ZQ3bxQ42/rInoD5rm+AO3Ip93n7Le7YEKuJNp53BOXf8/L6DMy7TeXwzp4BYI+Z/GXY m0IrPbfxbCcsfeNcHPfpQDEAlAa70c2YWmsVUNP2yTQ2ajmNLyTbCbD2rSZ94QCZTPCh u2HxhIVEPp2lyjy2kn1I4Tn8nElJg8b+H/eFN/Wp5+EqzsKctpZtpqdeL06XX4yBF1gO dEvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769754978; x=1770359778; 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=Wd1ua9oQn9fAQypNUkPZk/Pg7uXlEBYqtmR2BH2rdoA=; b=MpfLeTnXJ9jZuYT1Gy5aqWc2btkZBuBVTmK2Ek5m0r5MR5m9BzpW5lCUyQWvWSsd4W AZ7QYXKdfdt78+WvEiEKBcl+D7LEBzmhLYXBFjMIVhh2nM5wM3cwALlcuRfpr7yb90Lg MTXwH9L18xP+g+nfu2vCgaSepbXtUhyavnlsa36kSvEE3ViC0mXi/uWDJH6KY3RFY7oV RQ9ZE7aDlg3OQ+2hVee1okdD/0XZt/e9awWSdAQh4Rkytk5IOTehD3werzOgsAU0Jzxa z/0Vx/AZ3kuCPJeUyV0nF+yHR8Jt70lWnGlXfw4SmUyxHTlF54hstfWEE17ZPdJRF+8o 9U7A== X-Forwarded-Encrypted: i=1; AJvYcCV/+Cbc8n/KmDsN7JwqH9/82Na9irWmlsK5qrmFPXiFlEQEWbZdUE72RTujExziHKMbZuZ9qmukBtoV4xQS@lists.postgresql.org X-Gm-Message-State: AOJu0YxVP5SG4rTQSQkyA60zcwefkd2y7sPJJ7PbYfVFfA3EuACTVi4B 4W72UZIyC59ZUKmj2qn3x7HTzZaLSHolbd92FlR3iYrVcrm/QJ2o/kKAKbn5OHo18xoX05WpKdB tLbdO4vwANiHvWeJCjz6XLMUcE4KOVR0= X-Gm-Gg: AZuq6aI1yKKZetAEFzhBQ71022SXs91dzxnVy1ImCaHrikRc0zJCF+GNfGeln/nDsFJ b63fwiD+vSqQwfNOn6WX5ZAWj6s4BR+9Elksyk/aYAB0l2ScIvl6Z20JIl9rORPKFRckFRVtWpd bzN9afoT8dD+rqMpCCVaEOruN/tKMDZNmkS1QZtKVGr+vqekRsHykMrPcMmrSOolo7gGMDt5ipz 4lMadKirHkA/GGb1mCqC+mexyMHD8RUO9B/1t6Ib7o68s0B/6eG3mazw4vAYO1l5kt5SpQ4lpRk B9TZs1TvJ8iqlFWWovc8XjV/uQ== X-Received: by 2002:a05:6512:1301:b0:59b:9f59:c15 with SMTP id 2adb3069b0e04-59e164420dbmr584991e87.38.1769754977017; Thu, 29 Jan 2026 22:36:17 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dilip Kumar Date: Fri, 30 Jan 2026 12:05:59 +0530 X-Gm-Features: AZwV_QiipSmAgZWOcIoC5sRmje6Wn_Oehmp2LV-NSYw0PCMh__oTLvXpN3FHFF4 Message-ID: Subject: Re: Proposal: Conflict log history table for Logical Replication To: shveta malik Cc: Peter Smith , vignesh C , 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 Thu, Jan 29, 2026 at 4:46=E2=80=AFPM shveta malik wrote: > > Dilip, I was testing patch002, few observations: > > 1) > remote_commit_ts is '2026-01-29 14:38:02.777599+05:30' while > local_conflicts.commit_ts is of format > '2026-01-29T14:37:35.805819+05:30' i.e. a 'T' to separate date and > time in local-commit_ts case. IIUC, this is the expected (standard) > way for timestamps to be in json-format. Can you please confirm? Yes, I will check that and respond. > 2) > Differences between LOG and TABLE: > > a) In LOG, the column names are not included in the remote or local > tuples, whereas in the TABLE, they are. For example: > > LOG: Could not apply remote change: remote row (2, 3, 4) > TABLE: remote_tuple: {"a":2,"b":3,"c":4} > b) remote_commit_ts is not recorded in LOG, but it is included in the TAB= LE. > > IMO, both of these differences are okay as TABLE is expected to store > (or can store) more detailed information. I=E2=80=99m just noting these h= ere > for others=E2=80=99 input. Let me know your thoughts. Yeah, I think we do need additional data for table e.g. column name in tuple so that users can use queries to extract value for specific columns etc. > 3) > If we look at the table overall, the name 'local_conflicts' can be a > bit misleading. This column actually stores the details about local > rows involved in a conflict, rather than describing the conflict > itself. See example below. A clearer name might be local_data, > local_tuples_data, or local_tuples_detail. Thoughts? > > local_conflicts for one update_exists: > {"{\"xid\":\"791\",\"commit_ts\":\"2026-01-29T14:37:35.805819+05:30\",\"o= rigin\":null,\"key\":{\"i\":40},\"tuple\":{\"i\":40,\"j\":10}}"} IMHO can we name it local_conflict_tuples? Because remote tuples may conflict with multiple local tuples, I think local_conflict_tuple might be more relevant. But OTOH we are storing other information as well, not just tuples so maybe local_tuples_detail/local_tuples_info/local_tuples_data make more sense. So maybe I am fine with 'local_tuples_detail' lets see if there are any other thoughts? > ~~ > > patch002 works well in my testing done so far. > > thanks > Shveta --=20 Regards, Dilip Kumar Google