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 1wcjhA-003aBx-2T for pgsql-hackers@arkaria.postgresql.org; Thu, 25 Jun 2026 13:00:41 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wcjh9-005iJo-2M for pgsql-hackers@arkaria.postgresql.org; Thu, 25 Jun 2026 13:00:39 +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 1wcjh9-005iJg-0f for pgsql-hackers@lists.postgresql.org; Thu, 25 Jun 2026 13:00:39 +0000 Received: from mail-lj1-x22e.google.com ([2a00:1450:4864:20::22e]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wcjh7-00000000BgL-2ATb for pgsql-hackers@lists.postgresql.org; Thu, 25 Jun 2026 13:00:38 +0000 Received: by mail-lj1-x22e.google.com with SMTP id 38308e7fff4ca-396669329fbso7443111fa.0 for ; Thu, 25 Jun 2026 06:00:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1782392435; cv=none; d=google.com; s=arc-20260327; b=rWgpwnv+6o0PlqWCVAIXFoMowSRUh8wFg8W0yDpxNbo8UpTivttrfEz6lsdS3ztFik u/xUsO/obt5BWC6Ev1ssVfDQMwYs/4keKn8B4OgDTksANo02f05WPWd44IsiSO4LF3pP qYvmUM+Z+rgOx2si+fKdy81zhxGSMCofiZ2F0v9zoFVx9ol+fBK/SKgoGtUEks0ueGbR gl8nfP73tpfh9XzKCrsO9oL70fp7KLNDYk9lYLo7kmAewk3w7pYHAof/EHF8gCMnH5s3 u2gSHY8h4PsYRYgZPOmJ4zKQLJltndQN0lyedS7Fc11+t2YcxUPTrbO73YT08jZ6/dKN P8WA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=E4yeIGbbP2E/SgD9Ry6tiWcS1RNGLNJa0i2UGMpINQY=; fh=3f2CeSgwM/pOKdNZQYWEawUshG1IS9V/8ZUvcmjwfYM=; b=qe97aRd/mUIKdGhsauCD4fvHuimThQuXQjkhTVk6aKhLZxZ8ZC+TkiebCySj55H+/b cEBA72tl25GQQ7eUZWGttyVKmcPCAochfTINJi7/R+qU96S74RAU5/sO7szpEpZOhBCk dKIqZwZO3IFA2s7Z+rxA0ctnsGjM7wqx1MjQsDCzoK+7iiB8eCJGQjlObE79cqyN780S FIwj7lArwIyxOEoc4Uf3fwQlNGFmknadeA/D/MO65sSpwFfwr/pb8I0qeXGNJPEIKxEi v8Xn6JLGR7eLoxcSNU/qyxoVAwCddvHT27SJppl948gBhzvVSz5orYCb97g/MrbMNmXk iJzw==; 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=1782392435; x=1782997235; 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=E4yeIGbbP2E/SgD9Ry6tiWcS1RNGLNJa0i2UGMpINQY=; b=PE8LgOWelNRIs4KAuCEiqImvRTZzHSqXao2fr1uwRcrv/Hls48i2+8HRG6gPZgQLLw Mi/DUtA9TeoP8MVNsn6zWOpQbHDUH+7Tnbt6M9OBxWOiqErsbxS0MUdVDkyvGWRSss9T pQjNetLZKKXlDhWVqfNkp797+53koERBxnGOwpXqKka/4otB0RbT5cYr0EeCM7ctfSe5 Zz3Msw5vUIaZjwAlXjbvPH+8UhXoWCpmEf8MxxGIKUEbiOlo7haHo9mC/N29uFFQ5E1v v0NolAlIX9RJDBISwHcdj+Qbx3olpvRmX+3/H++/B4c+NxQtwHsMk2FsL0GlxeCYAqeQ scuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782392435; x=1782997235; 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=E4yeIGbbP2E/SgD9Ry6tiWcS1RNGLNJa0i2UGMpINQY=; b=GDheO+cCi67cF/1UGqBTGcV6KA0iAzj10SLhUMNykNlLWn/HdFEsB5Dzav7/HPKnFZ 6QLND4ZBfudR20uAZ+gPZ2E1ziF1q489Ww0wi/Zr4qT2mMNmpkYNn8TFIB4oMyKXaEvM vo2KCrKW9NVZsjot2iie7gBwnvt/oW4ZFZV6xzbkA75HZe/isyj7bk6AmDa7n0MXby/A 0HrcLa5OuGypYpVjk4np4rz5N4R+2KWWOwiVs8U0bYpd3GnctK6C7/yHkOLrzDTY/NKl wN+X8qBP1FcnqKehXpZytToMReNn6xmaYEWyPmGCeE3E8jMmIAAEGFtV0cvii49tWZ1j H2ow== X-Forwarded-Encrypted: i=1; AHgh+Rp7DAX5wC+g7ZqpFhIktBkzu7n+x7AeKWxL9FiQR+phzypUDjEHy2/MGlGZJ/kFxJh6a0m9Ys/FCqJN4CX/@lists.postgresql.org X-Gm-Message-State: AOJu0Yy9pGeU9KZw1UNa0s6s59btU2XVTohPswJYPvFKOFcAcBZyS/T+ GaJuB8bX53yqVNBKu8XuF04x31H4Ygtedp1Wd5qXQNm1HtEuBLrw4lB8klyVK0pEOth5j0P3g8J jbBfWYBhkggKKokb+ejjliM1yXmukE6k= X-Gm-Gg: AfdE7clXfLGWhgvBA3WWYoR8xXeRDAsw75yuhacAx4mjL6RoRG+oEJi2XgmHHARoJku +63nxFC0pHIy46q75M3dWdgZH74UhpVc0BuwW4LB9AtlE7Vz2etvT1XImMAIF0Jc/K60gyUJtRX aOp48oELrDrlU4FYhWMNpgdB+v6ANuylQEKhOWZgR/LC8uaDghEFUT3BReXRTS+2xGlfz3XonXr sdoGJvaNsEweZB/Up8kdNPj93m0f0mWQ6Dwisl1KyQEntNSJeFAjqYrydmswPyOtHJzpL+G8Ix/ mV3vWDxSBtrP53dmQgcovIjadLz/ X-Received: by 2002:a05:6512:6c8:b0:5ae:a4f9:fcb with SMTP id 2adb3069b0e04-5aea4f9109bmr148165e87.12.1782392433078; Thu, 25 Jun 2026 06:00:33 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dilip Kumar Date: Thu, 25 Jun 2026 18:30:16 +0530 X-Gm-Features: AVVi8Cd-kxgS4RnFG8hRt48x8J5lLrVHSpB2Z6wTJkxxwgn67Syl3J0-0ll3tL4 Message-ID: Subject: Re: Proposal: Conflict log history table for Logical Replication To: Amit Kapila Cc: vignesh C , Nisha Moond , shveta malik , Peter Smith , 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, Jun 25, 2026 at 4:57=E2=80=AFPM Amit Kapila wrote: > > On Thu, Jun 25, 2026 at 10:34=E2=80=AFAM vignesh C = wrote: > > > > On Wed, 24 Jun 2026 at 19:27, Dilip Kumar wrote= : > > > > > > > 2) jsonb supports indexing, whereas json does not. Was json chosen > > here because inserts are faster due to the lack of parsing and binary > > conversion? > > > > I think it is more because the local/remote tuples are usually data > which we want users to see as it was in original tables, using jsonb > can change the ordering of columns or remove some space etc. We can > add a comment on the lines of: "preserve the exact tuple > representation (column order, formatting) for the audit record; the > value is natively json so this avoids a per-conflict conversion". Now, > this is true for tuple data but I am not so sure if the same thing > applies to the replica_identity column in CLT. Would users ever want > to query using ORDER/GROUP BY on replica_identity or use DISTINCT on > it, because if that is possible then the current schema would result > into ERROR as follows: > postgres=3D# select * from pg_conflict.pg_conflict_log_16394 order by > replica_identity; > ERROR: could not identify an ordering operator for type json > > This needs more thoughts from the perspective of how users would like > to fetch the data. > > Few other comments: > * errdetail("Conflict log tables are system-managed and only support > cleanup via DELETE or TRUNCATE.") > > In the above message 'via' sounds a bit odd, can we instead use > 'using' aka "Conflict log tables are system-managed and only support > cleanup using DELETE or TRUNCATE." Okay > 2. > @@ -2482,6 +2681,8 @@ DropSubscription(DropSubscriptionStmt *stmt, > bool isTopLevel) > deleteDependencyRecordsFor(SubscriptionRelationId, subid, false); > deleteSharedDependencyRecordsFor(SubscriptionRelationId, subid, 0); > > + drop_sub_conflict_log_table(subid, subname, subconflictlogrelid); > > It would be better to drop the table before cleaning up the dependency > record. Right now, it is okay even in current order because dependency > removal is trying to remove where subid is depender. So whats your suggestion change it now or not? I feel either way is fine. > Apart from above, attached contains a cosmetic/comment improvement patch. Okay, I will merge --=20 Regards, Dilip Kumar Google