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 1wZ6r3-000mPu-1h for pgsql-hackers@arkaria.postgresql.org; Mon, 15 Jun 2026 12:55: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 1wZ6r2-00BuXm-0F for pgsql-hackers@arkaria.postgresql.org; Mon, 15 Jun 2026 12:55: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 1wZ6r1-00BuXe-2I for pgsql-hackers@lists.postgresql.org; Mon, 15 Jun 2026 12:55:51 +0000 Received: from mail-pj1-x102b.google.com ([2607:f8b0:4864:20::102b]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wZ6qz-00000000VyM-0SSL for pgsql-hackers@lists.postgresql.org; Mon, 15 Jun 2026 12:55:50 +0000 Received: by mail-pj1-x102b.google.com with SMTP id 98e67ed59e1d1-36d8b644473so2867149a91.3 for ; Mon, 15 Jun 2026 05:55:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1781528147; cv=none; d=google.com; s=arc-20240605; b=lCRWCbEikiX+IprT0Fx+OxlGmyLF2vjUnh6MisfuNDxuNmlowktZszEP2X0L+w3nO0 oY+ShOleolHEhwoEQeOsjWWB99XSpBn5+Tz27cS5PbAQE3d7xqW8bQ5tHDVOisoZxEuR CA6tzNbqzb2QruQuRKAR7SdvgUNQLlvyV8VCvefO4sPthOVEPkqkDpt20vXJtzRPayX4 zOijH3wDnArRUemsZCDAb/fcZkSu4GTAXj48QpSui5W7v9EX5GPmgOeFdnWEkaNzbmP1 saAWOBWK6gs47p9cjhaQM7Oxo+WEbCXAwpWxD9Ue9oOhpsZO3XMuCgnJ0/QJGDlSOooV jFmg== 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=AwusGvax1Y8AQRdJVlXQl5/E3AykPUBSJKzsROzYtBM=; fh=Xna5JFujkkAuq6FA3OvPBDX3z1iLrX+g+dK1wsdoMkI=; b=Um/CrYom3fodh9wXEE/m6Vs5s7tKR937pqPVJgV24TohAnMZv65yeZ4gNzlM7muzUv H+glDnMghxCAWoX91+U7DZuo9NZdXfbREU18980G/YEsJy3z3CrXX/+MpEON9PyQISb2 4shtTr1eZxK8mFV2vm98zG+7HMe/MVBeXIwp0GlGz3gp5lEf6Z5tp4CIRukfk/F1GuoN wKr1TY4Nlrlm9GyLqo2cj2j93yDCYR33ItWohVBQ2FvdzhsFpO262MQgTvFROnsvo8pY MuXv9X2UQVwIrxfUeD7NSWhp46J1jVSfOfsEtUzHVV7YoqMtEqLlQZL/i5ya0X2NLf26 aPGA==; 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=1781528147; x=1782132947; 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=AwusGvax1Y8AQRdJVlXQl5/E3AykPUBSJKzsROzYtBM=; b=NSUwJDIqOktLUdr2myfD8A6c6UayYeM3yYH7VqyFWVn842b2i5cqskyo1KjzaV0ljp t/y0Qn5Hn3d8H0rjP7yS8a00X9eRE0sf0eDcvATyF868B1W5Pcp/eG7HL7spBymMj5E9 97Obh8ztvxAcJJdTxTOcmC3A3RlZWWzZv5w/XUldCcmzkbOgokTXfoK/ytEgKUY3MrnH XGdekgWyK1bJpqDeici1PlGQBBLSTl9zv2ox3DUVuCr9+xzkXq87FETzLdl3zxm+xYPZ ufgqwt/wNi409kozdoN872otiPDqlAPC9Io6hbmgT3B2C7/EqiAZOrbvbgvENRdQiiBS jXnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781528147; x=1782132947; 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=AwusGvax1Y8AQRdJVlXQl5/E3AykPUBSJKzsROzYtBM=; b=HGxWZ/nWNpClkzxxsxuSm8HAX1bfa4dY4N4sUMLf1QWkwiioBASxV6J1ajJCbaH4YH GGtoQdT/1lxCuv2Z9SfAWMoF754mKEDbfdv8ilAyqo7TZOKT+5D+vnmrvwhdBVGNL25L eT8mtO0YNZGJjS4JeLf8woqvEgjd65NbqbA4YYm98aHyaPoq6eGH4L7wlIvHzGvOPk57 FvycCprFpe3TE/40NiR2RliK0VaDB6k1HLb/5vaKX7xYuO4kelrpNCVIzoIx3O4P8I0B VjGjlFrwEO1iLeGnGhvMmDgsgCX1aCAY4yt/fTwPAbFvp8zQSRq/PmBKtSdGpc7kKOGM LGkw== X-Forwarded-Encrypted: i=1; AFNElJ9ap8zorHpgW2b5WCMGoCtaCvFC1sTpeuXd3oUxU9UT/6XTvODwNQ9Zk7T8fRxTaSMSJkdvjK+REVdaF4cV@lists.postgresql.org X-Gm-Message-State: AOJu0YyO3XHb1afrHtYwayoS+XKrlDBm7ol4WWSlYAexJw3kOnmVBXY+ DzBeS6W/GA32gTLlHJJ9lxhTyt5TzHbVo8OJXipAwZQVUBoH5dC5NvFKHsv/tpQwe1RHxnpTVd8 hJEve1wZVOTN4DV9HG54NMeAiszfYeaU= X-Gm-Gg: Acq92OFg2rBNoWEGEF6loLG/9pervXhx0oSzr1wGL8OyR3xFtDzY8bemO8PyxpQ8S+e Yb1uUH7Wi8pCSJJe422t0czcG/x90/ct2DqCXIHCYUHIbiWd7CSJIJQJ98Tl+zurLYEdqXTXOtH KBHas2Ap1Bj/oDHmpkSH/hhC3OIHleOH86LUupt5YultjaSZpbXv7ygWW6WTkGBC9xgRBAY9TsB fh4b89dsLkVs6dyahG47f92QKDizC3n0rNlUUOIIN+gkfyrh86JnH4QJaXCtW7F2eSXjI8BWReB 6M32woAMz6AHqYQDsLC//8LlDV301pusuvpYG0LIqN41hWSeojwVZA== X-Received: by 2002:a17:90a:fc45:b0:377:36af:c996 with SMTP id 98e67ed59e1d1-37a040b3518mr15024142a91.21.1781528146889; Mon, 15 Jun 2026 05:55:46 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: shveta malik Date: Mon, 15 Jun 2026 18:25:33 +0530 X-Gm-Features: AVVi8CfdBhLCzAnbyvhBc9EpBrkpNo81MeqfwOl550yI2kB16_uhgpojZ2oJ1eA Message-ID: Subject: Re: Proposal: Conflict log history table for Logical Replication To: Dilip Kumar Cc: Shlok Kyal , vignesh C , Amit Kapila , Nisha Moond , Peter Smith , 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, Jun 15, 2026 at 4:45=E2=80=AFPM Dilip Kumar = wrote: > > On Mon, Jun 15, 2026 at 11:27=E2=80=AFAM shveta malik wrote: > > > > A few comments on v50: > > > > > > 1) > > + /* > > + * Conflict log tables are used internally for logical replication > > + * conflict logging and should not have extended statistics, as it > > + * could disrupt conflict logging. > > + */ > > > > Suggestion: > > /* > > * Conflict log tables are system-managed tables used internally for > > * logical replication conflict logging. Similar to indexes, user-defin= ed > > * extended statistics are not supported on these tables at present. > > */ > > I think the reason for index are different so here is my proposal for thi= s > > /* > * Conflict log tables are system-managed tables used internally = for > * logical replication conflict logging. Unlike user tables, they= are > * not expected to have complex query usage, so to keep things si= mple, > * user-defined extended statistics are not required or supported= at > * present. > */ Works for me. > > > 2) > > Assertion hit in alter_sub_conflict_log_dest(): > > > > > > set allow_system_table_mods=3Don > > create subscription sub1 connection '...' publication pub1 > > WITH(conflict_log_destination=3D'log'); > > select oid from pg_subscription; > > > > --CREATE clt USING SAME oid > > create table pg_conflict.pg_conflict_log_16501(i int); > > > > --change destination to table/all > > alter subscription sub1 SET (CONFLICT_LOG_DESTINATION =3D 'ALL'); > > > > --this asserts here: > > 2026-06-15 11:10:40.540 IST [10626] LOG: background worker "logical > > replication tablesync worker" (PID 11397) exited with exit code 1 > > TRAP: failed Assert("IsBinaryUpgrade"), File: "subscriptioncmds.c", > > Line: 1554, PID: 10662 > > > > alter_sub_conflict_log_dest(): Assert(IsBinaryUpgrade); > > > > Should we fix Assert or restrict table creation in pg_conflict scehma? > > We allow it for toast-schema though when allow_system_table_mods=3DON. > > But I don't see a use case for allowing this. > > I think this is in 0004 patch, because during upgrade we would have an > existing table created via schema dump, and hence we need to associate > this table to the subscription. But I am surprise to see that > changinng destination from 'log' to 'all' is going in that path where > table already exists, This is because we compute want_table and has_oldtable purely based on old and new settings (not looking at table existence actually), so the old setting is !has_oldtable and new is want_table, thus hitting the Assert. IMO, it should be ERROR (similar to create_conflict_log_table) rather than Assert if the table exists and the mode is not BinaryUpgrade. Thanks Shveta