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 1wV3cR-001eQj-03 for pgsql-hackers@arkaria.postgresql.org; Thu, 04 Jun 2026 08:40:03 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wV3cO-005YYI-2F for pgsql-hackers@arkaria.postgresql.org; Thu, 04 Jun 2026 08:40:00 +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 1wV3cO-005YY9-0n for pgsql-hackers@lists.postgresql.org; Thu, 04 Jun 2026 08:40:00 +0000 Received: from mail-lf1-x136.google.com ([2a00:1450:4864:20::136]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wV3cL-00000001Cr2-3AvN for pgsql-hackers@lists.postgresql.org; Thu, 04 Jun 2026 08:39:59 +0000 Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-5aa5ce4904eso481904e87.3 for ; Thu, 04 Jun 2026 01:39:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1780562396; cv=none; d=google.com; s=arc-20240605; b=XRPRTBPFG8ivjCdm+n9TJnpo7AELAu7teQ3qRxqo6bIHfXCFUosJIPyssdPkFJ+qQl cVbKACrtARNBM7mA4mKkG87raQUI1x5EnA8VxzrGvCKO6sBwyoaPo2MVzFJ1QnsfR9uJ CC5SkU/hs766dsWIx2Byu0docbcXsjULUE2cHmbdJKCAE6fqWpDg08x/EEWpVPlTHmZy n1ZJ7XnKhLVN3vLPmCHKn2zxOT/McHNkcnvCRYxXUZCZvKqsX8T4Dz22vR8wwcp7pw6I LbtZ1Xm2OfU+hLVB/Ha3Or4QYkRY6ROx4B6mfQ3xav5VFk484G78Rhi4cit8e+yiH+V2 f3gw== 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=kkcSJpYaFkENKRiPWROd4myltCXdCrpM5yhsQHt+sXk=; fh=XqcpsWKi2np8yrVPo9AqaJcy6jNu909zUWY0qgaLa/E=; b=KIFjBZ+HH9JeCaSNpzHajuhpWgymjyrjOQtlFRLfAfWGQMt1XYiXe+eKS24G+2LbOP jrAiiLFP8E5m0INmy8ouGwIv+Yn7wGw8KjjjmQebek7S+8PoOm9vz/SwZBbwjNm3uT2F QJ32PwwX/l4xGOMF2OjyiTabXo3xnYGrExsidF5SnI8DGf2AWLu0IH16dDXEfq8S+Rk6 Kecy9Wh2xoGogNFpIsxVXNgV5ade3gztvM/f744xu3IMPh9WjTYz6kt+VnIsmuGM/oqt SxqdIu51ZlJqKsyBYhzQS/fHmXYrc8/Z9kDHWqiovh+H4MaUMwR2BIJYL64Mg59ppbuf LxiA==; 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=1780562396; x=1781167196; 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=kkcSJpYaFkENKRiPWROd4myltCXdCrpM5yhsQHt+sXk=; b=PcjBzjsYr6UIB7M7wG2R3g+NUN8S/jSdDT5j5v1bLtZ8GBTzYcB0H/WP4Fy/ukC8TZ DcqcuEgeY4lUerztfRzMm/FPteAFhy3mBzZj+NU15lvG2uUeBkh28CQIUHLL+FVA7pU8 raX/ca0uH1oLMp9WranjdnFa1vLMonYq22fKGiHs8l+KQjLlh1PXCMOCZbBXHTe3eJA6 O5CnsPxCcOCOWx/5HGxjvwbFr5Emeiy3qirPHjVhigtPke0IHsyt3SzCGI1NKKYv6KhX gZrcFh0jcBCZ5OhI5sPl4e230ZyJpl8AqoYcDiMokh2OPiPsuUmc9D/4C0hrX0a7tLuS jK2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780562396; x=1781167196; 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=kkcSJpYaFkENKRiPWROd4myltCXdCrpM5yhsQHt+sXk=; b=S+tNAnqhxBbDEk5EopadTSZZcEOfZwfWKRGyjO94rx+BgBTziSiUEA8iU6wlERy/4+ +0PE4VzL9ZFiY9+0WzJDrnkd2Z0hwIj4IIQEaeGGS7LsCxmwyEJP/raRJPJAInpF/Sgh zMCjNWOvbKjcrWv/oxJ6SEAu2AZudzausb7V8x7EQaIWN3gq+xl8EpTdhQpFl9+hiqwl znRnT6M+qtNYZM39jq91miykjJ27FwfNbJ5Cyk1EOp4OjDisDTthEUMvNuaC4EDyI/uM /Cu0eFwEri1q7r3f63W4lAJJBNH3NntF8spySwyH4+R+8OzPI3Qo2BeAhujRdZw3bi4b 7ZCQ== X-Forwarded-Encrypted: i=1; AFNElJ9oaBEWkYQZV3/7LIG520zdLO+DVPYjvnousosKiCLEVHZnsmhW3MnebwISC7RmlAAjjl104bkHVH6WJufl@lists.postgresql.org X-Gm-Message-State: AOJu0YxcgB1teP5ZdomtdQHVA8gwGUbAxrrdoOAaqdM7oxqbgqIW1P/b KVnP6CPKPFkhM5DIpKyHm+qJJUJZfPwrmloQtgEBVmiR/FpvvI/xJPnQeici2tiOVvYbdaIi1f2 x9Ht0jdS9QVpUS1iYASqcpEnClus1WB4= X-Gm-Gg: Acq92OFQAppyKK7NpJdjiOAk+hRf/dQdiwpI+giQAzid3Wf9uZH8NjLrYHM66K1SNc3 wmIqDnvc/LbMMKgTeQbiT5W9H+8pzu2vKBK5Y3pPDezw5/pcoj4xrfolfHYn7nv+mlvWyIXPf7A cQxiMEEYr2dwO1emXoJt0ABRIMkiNEXSQ5nD4FZX5Wkf/NQPtWGp5DQXAgbUaRaFSai4vTqjSAF 6f2LmnGAJEwEBMoAukxGQnnrG7emtDHJTWuUXevIM+SLaJ+oo+hZwUAXuOCIdcUzvLLldcPsNQ8 tJI/+pNaMAzny7qSXJqONCU7mRJ+nEZmQM2/8CVyMSczHf/n X-Received: by 2002:a05:6512:378b:20b0:5aa:655b:ac29 with SMTP id 2adb3069b0e04-5aa7c08bf82mr1824541e87.13.1780562395575; Thu, 04 Jun 2026 01:39:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dilip Kumar Date: Thu, 4 Jun 2026 14:09:36 +0530 X-Gm-Features: AVVi8CdY4Ct8nEPN8RqHZDBYGZvscJSpFLV-U-soQuFutbM11sZjgCJaYr81YL4 Message-ID: Subject: Re: Proposal: Conflict log history table for Logical Replication To: Nisha Moond Cc: vignesh C , Amit Kapila , Peter Smith , shveta malik , 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 Wed, Jun 3, 2026 at 4:18=E2=80=AFPM Nisha Moond wrote: > > On Wed, Jun 3, 2026 at 3:24=E2=80=AFPM Nisha Moond wrote: > > > > Thanks for the updated patches, please find my comments on the v44 > > patches below. These appear to apply to v45-001 and v45-002 as well, > > as both are unchanged. > > > > Here are couple more issues found during tests: > > 5) remote_commit_ts is available when streaming=3Don, in that case, we > are not updating it and hence see NULL in the CLT. > A simple test case: > -- publisher > ALTER SYSTEM SET logical_decoding_work_mem =3D '64kB'; > SELECT pg_reload_conf(); > CREATE TABLE t (a int PRIMARY KEY); > CREATE PUBLICATION pub FOR TABLE t; > > -- subscriber (pre-insert the conflicting row, so copy_data=3Dfalse) > CREATE TABLE t (a int PRIMARY KEY); > INSERT INTO t VALUES (1); > CREATE SUBSCRIPTION sub > CONNECTION 'host=3Dlocalhost port=3D9933 dbname=3Dpostgres' > PUBLICATION pub WITH (conflict_log_destination =3D 'all', streaming > =3D on, copy_data =3D false); > > Trigger a streaming conflict > -- publisher > BEGIN; > INSERT INTO t SELECT generate_series(2, 50000); > INSERT INTO t VALUES (1); -- conflicts with subscriber's existin= g row > COMMIT; > > Check the CLT - remote_commit_ts is NULL despite timestamp being known > -- subscriber > SELECT conflict_type, remote_commit_ts, remote_commit_lsn > FROM pg_conflict.pg_conflict_log_; > conflict_type | remote_commit_ts | remote_commit_lsn > ----------------+------------------+------------------- > insert_exists | | 0/1234ABC > > I think we need to update it in apply_handle_stream_commit() -> case > TRANS_LEADER_APPLY: > remote_commit_ts =3D commit_data.committime; Yeah we need to fix this, I will fix in next version. > > 6) Different ERRORs for superuser vs non-superuser > I created a subscription owned by a non-superuser (nisha), and the CLT > for it is: > postgres=3D# \d > List of relations > Schema | Name | Type | Owner > -------------+-----------------------+-------+--------- > pg_conflict | pg_conflict_log_16469 | table | nisha > > > Now if I try to UPDATE the CLT as a superuser: > > postgres=3D# update pg_conflict_log_16469 set conflict_type=3D > 'INSERT_EXIST' where conflict_type=3D'insert_exists'; > ERROR: cannot modify or insert data into conflict log table > "pg_conflict_log_16469" > DETAIL: Conflict log tables are system-managed and only support > cleanup via DELETE or TRUNCATE. > > However, running the same command as nisha (the sub/clt owner) results in= : > > postgres=3D# SET SESSION AUTHORIZATION nisha; > SET > postgres=3D> update pg_conflict_log_16469 set conflict_type=3D > 'INSERT_EXIST' where conflict_type=3D'insert_exists'; > ERROR: permission denied for table pg_conflict_log_16469 > > I think the error should be consistent with the superuser case, rather > than failing with a generic permission error. This has already been discussed, and the same behavior difference exists for the toast table as well, because for superuser we do not mask the permission at acl check instead we block at the operation level however for non superuser it is blocked at the acl check and we are keeping the same behavious for the conflict log table as well. --=20 Regards, Dilip Kumar Google