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 1wRoFD-002igu-2w for pgsql-hackers@arkaria.postgresql.org; Tue, 26 May 2026 09:38:40 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wRoFB-004Baz-1X for pgsql-hackers@arkaria.postgresql.org; Tue, 26 May 2026 09:38:38 +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 1wRoFB-004Bar-02 for pgsql-hackers@lists.postgresql.org; Tue, 26 May 2026 09:38:38 +0000 Received: from mail-pg1-x52a.google.com ([2607:f8b0:4864:20::52a]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wRoF9-00000000pnY-3YgL for pgsql-hackers@lists.postgresql.org; Tue, 26 May 2026 09:38:36 +0000 Received: by mail-pg1-x52a.google.com with SMTP id 41be03b00d2f7-c80203b9d7bso4345739a12.0 for ; Tue, 26 May 2026 02:38:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1779788314; cv=none; d=google.com; s=arc-20240605; b=Ghhdohwns3CmR5hht220xSlVd1Dma6XHqUdxOuUvy74FEqs7TiCyICCQ5cjnBLVkvH AsXeVanZRODT5NHS1ajGfqj0UIfCxkYfpp82jnJa+22umOuIAdnLEEx21gZOQoO4GoGq Q6rjiWzhj5UjZuN9dshU7X3n4D/93p1vHHCh6jjWD0Dcn5ycqreRfhxsNc+IEJTWYjx5 65FYgwUnfFRFF86XI3QNwJks6i/pQY0R9HONe8lgtabIYZX88grUTz/hGE6bVwrVVQ8k iXcwnneNptiquvURo9HrhQU6pDl2A8rMQU+v6eHPEMCWwunqoqoS8on1FS9HdXPMMuhc b9CQ== 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=xoNpmPQZ752xUsyKARidcZoRAUbr2pdIwpTU8yNHOPM=; fh=JDYX7XTbTwjP+SRGu4xDvdIZUAFRB1/YKOQTNcqHSkY=; b=hInDySImor+rqRDLbtQk/XbbEGzSGlJ6XFR4mWu+nN4QRkXWzZM6PSQ7uUoBrTFcW5 7LfW5YEQaxzMQotWYKQ7N/PwLljts7wmtxswf908cmnH1iv3F1FJ5x/ztzN5q+PiAAWY ydt9+/wZkOIuZo3XKEQGfkocrgUBTZwjHvcuRft4lQ/9Xvzk8rYho30kL7AHMSqqyimQ 8+8V4jF7McqqxKjXFPEVCBKrvQnSfK1gdK9LL4Y59oNrAGBqC7attX1o6iRtnRKQDgY8 0G/qnG110GPuWOusjlucx6kHwDTZ39KrgFS1hqyVmAGl6dZvvNC535xTsJAJCWPvA7Uf K9dQ==; 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=1779788314; x=1780393114; 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=xoNpmPQZ752xUsyKARidcZoRAUbr2pdIwpTU8yNHOPM=; b=Rw4HU6kEROJOakeiqoKGDwM2x7jq8qV7aXampPvcuL65fIhYOe38Pou4xWZwcQ5HbJ JkAkNcUMxx38ZlYbvv9DWH1hs2tSzd1zQ7m1dq0iA9gissRgHfQfgJrK/yqN3CFKCUxS +Mqso8cSvrKGZ+Sji1R04dMuxUCYVhAFUSlxCSQ1wzgmvlaCb7OYmjZa9QJlvSLXNZ01 DM4rjyM/Wc2g1EKy2z6Y/TooycyRPIhomD3OyMXLfAzKeKRv0kqFl93d449GxmWoG5qB rHgexXgKq8ca/w3CQpinmAdaoblprT4MmC5zF2JzFFHwMFoD2rSQewYGCknf1SAalkbk iIww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779788314; x=1780393114; 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=xoNpmPQZ752xUsyKARidcZoRAUbr2pdIwpTU8yNHOPM=; b=OnW+qO023sWNjGt/uMTV8GiV3SLvGi13cULMSeFTUd8PNfkPwAfY3rV41i69TH9ozD 8teiczeU/yi1rXOUlUa956N1nhGGEPK2m91/+nU8PGZ1a5j8Er7hvvjjRzHKHtehCGWt NcAGhvOwsAQqUHuIfBfwRX4WOPUeQCDMvgusqjS8qS/Jm/RnxHfkg3vmbUFzHBX2pmgt 67I/4Cdt5Mu1K8r6VTrVncx2HzIFfyDnG/nQ6fiM12jvOhnZu0d6HK+ruJV/HkjJDRSa yvYV2VWVHLQbp8cF0YYsVTZPd+mnqB1y1S1Z04Q3IsBD8BaVQQLhJ7R0AJY1O/p/EwZ1 bZNg== X-Forwarded-Encrypted: i=1; AFNElJ+W/R9qhqAkQvjuU+ZP9ewWfqBw8qVS9j6SzZJRcKE0tYAOGQz4MpdCIax5XvfMr40DOFCUbxofc2DRCoIw@lists.postgresql.org X-Gm-Message-State: AOJu0YytHfJV7QvHJ00Bh8gi8q5u4MvfcI/wg6Ptw7Ke9BvZQmPFSAHg sLHiTMI9hzb8UkzGEHknsX/Ny/Yry4rYSEflFvA3Bb8j82xUf/AOgrxYqfEHZqCqPm0tI0ETdi5 H5I2qfdAubNESv8jPbD+QjoZMGIaC7ss= X-Gm-Gg: Acq92OGIjgkQxgXyTWe+2kdtEWqtxoQNeW6m+jz0Z6jmnr73stqWP2JISC0m1yN1Nyn /IKmm6t4lCgmueH1NwAlF5fjH3x1rlO52ljluP5M4XJ9YIh8o94k0IvOSIK1JtlaNORIW/Sa/X2 tD/sHwCbVXY33blzEq7/+Nh5ooIVdhnEU1vBqxgYh0dnTYwRp0fq4z8FyActD3FHaBZ+JMZhjU8 pxy47GSMuNcim36VvPbEHKimhzqYBQh3Fj7No1x8BIbqRjbpVwowMTbf34+gX8DqiRb2sYa+XmG dIoXUz4aiEku9jTyvCV9L3zxW5BY4wiUE3zNt/1V/VMv5QfLrGBguA== X-Received: by 2002:a05:6300:4093:b0:3b1:a9ce:507e with SMTP id adf61e73a8af0-3b328e74594mr19323609637.32.1779788313921; Tue, 26 May 2026 02:38:33 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: shveta malik Date: Tue, 26 May 2026 15:08:19 +0530 X-Gm-Features: AVHnY4I5OAh3a8dOQMy0cqiIVMy7naFslUZ6egZu1bk2V4dbv_y3ZQPIvZIFgXE Message-ID: Subject: Re: Proposal: Conflict log history table for Logical Replication To: vignesh C Cc: Nisha Moond , Peter Smith , 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 Mon, May 25, 2026 at 10:13=E2=80=AFAM vignesh C wr= ote: > > > Thanks for the comments, the attached v39 version patch has the > changes for the same. > I have not yet looked at v40, but please find a few ocmments on v39-0001 and 0002 merged together. 1) heap_create: + errdetail("Conflict schema modifications are currently disallowed."))); LookupCreationNamespace: + errmsg("cannot move objects into or out of the pg_conflict schema"))); Can we make it same through-out, either we use 'Conflict schema' at both the places or pg_conflict schema. Since in these 2 functions, in previous messages, we are using names like 'System catalog', 'TOAST schema' etc, I think we can use Conflict schema at both the places. What do others think on this? 2) drop_subscription_dependencies(): + conflictrelname =3D get_rel_name(subconflictlogrelid); We can actually have a sanity check that we got the CLT using the relid. Assert(conflictrelname !=3D NULL); 3) + /* + * Special handling for the JSON array type for proper + * TupleDescInitEntry call. + */ + if (type_oid =3D=3D JSONARRAYOID) + type_oid =3D get_array_type(JSONOID); Why do we have this special handling? Do we expect that 'type_oid' can be different from JSONARRAYOID if we use get_array_type? On debugging, I found it to be same pre and post get_array_type() 4) Do we need to have CommandCounterIncrement() after heap_create_with_catalog() in create_conflict_log_table()? I think even if we are not doing any table_open etc for CLT in same transaction, we should call CommandCounterIncrement() (to be consistent with other such calls of heap_create_with_catalog and to make it future proof). Thoughts? thanks Shveta