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 1wZ0KX-000hBm-28 for pgsql-hackers@arkaria.postgresql.org; Mon, 15 Jun 2026 05:57: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 1wZ0KW-009vuk-1W for pgsql-hackers@arkaria.postgresql.org; Mon, 15 Jun 2026 05:57: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 1wZ0KW-009vuc-0P for pgsql-hackers@lists.postgresql.org; Mon, 15 Jun 2026 05:57:52 +0000 Received: from mail-pl1-x629.google.com ([2607:f8b0:4864:20::629]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wZ0KT-00000000Sso-1tQo for pgsql-hackers@lists.postgresql.org; Mon, 15 Jun 2026 05:57:51 +0000 Received: by mail-pl1-x629.google.com with SMTP id d9443c01a7336-2c0c32f6ce1so19479355ad.2 for ; Sun, 14 Jun 2026 22:57:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1781503067; cv=none; d=google.com; s=arc-20240605; b=K6s0NFCTmk4cbqbJDT6JI4zW9bKNAqTsU9YhKosbeJ8x5QAlYfVsIsmn0Q9d52IUks C7frIKvl+7Eb7vWds/anCQye+dTixLLm0jjKrtdu6PM8raxXbbglSp6EellUX3tt2gO2 ARYnl7UnhCTc9B8+20fFeZ0v1d3+aU2cwWoTctSra53b5YPl3rEouCmwGdjD3VnQOd6z xjnEmrDbHA2nLqAC2SKfNUe4YNyKv4/V82wGpML6xzkrNfFcaiAKtbG1quiTQiJ7Yx9f L8CFdPpxrNYKfFGRz/SA2SXRqJa80ecraHDE28U18Y0YR5QGxEXPt9avBPWyqxD34o1Y UeFA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=AMLDEO93B75D49fNqHPqJlEO/i8tP+wvePTH+Z7Ne8M=; fh=3555sjt3i4CCskeANRPIsOzTXntB2wljrpqpz5uPWhU=; b=kXR6sf6ehpwRtm4f1rODJLGb/eyatrlg7EcLOdoq+rqdggvS+S4op5L3EkWGFi5hSZ aNHm6McKUDdPOVAF89aR/ornPcLaWfG0ySTRBwc8oIR9uCAvDMeIyhQq/RL739+Vnwce sq4JB+sGSL5cwOe6e7Oby94e4iCC/BAC4EK+NUcVtoZ2ZGCeoa+WiMVlC8rqNHocdxhl ZORCiJo7Pw/FR4WQN52ISwJnpgsaqCyJSM0Ta/xt2Yodvy1xbFhIepvXmvaz+AhsoklZ wfEpLfTslFCRwMg3j6kNwCUEyiICsKjHXx8vstcpgvv/C/Ige62udJW8P3vD2YxBhjWC e2ng==; 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=1781503067; x=1782107867; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=AMLDEO93B75D49fNqHPqJlEO/i8tP+wvePTH+Z7Ne8M=; b=CbDcFWm5wvFf6z5KbfH2aXzl+qIRgRivhKvYy05jaR6Y83G7P8eMcGMQpAxB0aKoM4 z6BsnsTOcxUE3w+8reiKEj8cASNprEF8gvEwsyUljNzlWivXLjhpFnJlMsPVzG/oG04c FjJk7SxfmhzI5xfxemIRCqjXZshQ2JNbd9Y29wUhvsaxw0gGtJjbFbidkDXwvRJioqyP acdmlJD0/tTtcLTRhM9P9Z0B0VqW21U+XlrOzSA3i8mpvUELROSY8r2UjdoFV6I/dVmT viDV6LXrX1pBN2VtSWukSkv1fRJdjhyAEftOctcOp7NOm5mdYyAc8ypL1tymsnntGZQK z1/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781503067; x=1782107867; h=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=AMLDEO93B75D49fNqHPqJlEO/i8tP+wvePTH+Z7Ne8M=; b=iptjDUL+8h2Qv/BcIztqWcPJfNMsv+oKTzQtRTSKXDIcHLZ2sAJdE4BfsUk6C7flZw TLvzD2BAVhvPeJX8rawD4RXxLQH9FqcMY+Yz2nNlVKVCtaMRRZ6mf2ziNE/j1qOdtSBI 5oATsVvdtDuWuUELRhfkIe23Gi21YC4K6weuj/OAh4lBQP4ws554BH8gwAGHAwz6pOEG sbvYFLjuZOMxoGEsKEgpkPiEbq4NFGyQ8Z06Q140XW2Df/YXxyVXMxPsgAJShTrFZZt9 qhldhp6ojXjPymSm8Sz29lEmz932TR7V+vjiF14Y5xPQ0RBefTTM2R4aCuKT596Rbt4O 3o7w== X-Forwarded-Encrypted: i=1; AFNElJ+nWVH80HcdYp7X6VIX0ex8BL8qrAGJyOf8pEz/U+cL+qCmYUsfHReAN771WYzC531Yc9ycyx5kEsJrtjRE@lists.postgresql.org X-Gm-Message-State: AOJu0Ywaqaiga097Ehv2Wa5UH2qhL+OI7JyxG6Q/Lu8C2rDrSejtl6Ik ZYZFYxMokaOkjx/W1NND3PaJuPapYFxCf6FdpjtNG4rXxIyzjY1gSELj94nMfedMql9frkZ6wps RHcvGmLKVenYLkKZhxj3JzgquIcko0Og= X-Gm-Gg: Acq92OHARup8xj6/5CTUAxyNck5rAVZNYU4cZgp8ZYncjKmrlBj/NVGVye5+VM7aDf+ AKaugt8K6tJCei7uwMRrI2RM1WmUjBpifX7/xNVBQSy9/LIjddb72NnPbq/NuFTMYN1HqLSdP2T mnxMreh0hqbNH5c88Gp7f1vteuZqqVMhJ5/Q0q/4vLAwHrXYGrTE4AlE3yHFpnc8oTEFh41nwdM 9hp9WFrFXIMekStvPYhHBJ/AfTQpTBB5EtMRbh8ljsePYYxPM8EVSYZcGx0AXQJ9eVIrULCtzd4 5rLNajrU2gDYNMyIO0o3B2eD/Sq0w9YVM0BurpqvoYNtQ3IiI+P3W9lAICwM5M2awP5q3PY9DM9 7dHr0EVGysQ== X-Received: by 2002:a17:902:e5c6:b0:2bf:7b62:a02c with SMTP id d9443c01a7336-2c664148584mr112263935ad.3.1781503066985; Sun, 14 Jun 2026 22:57:46 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: shveta malik Date: Mon, 15 Jun 2026 11:27:34 +0530 X-Gm-Features: AVVi8CeP1MIiGPCaSJcW8TJ91OdLHBX8nXvCRAtCd7dYTtx4UKXDDkCrSK8kolQ Message-ID: Subject: Re: Proposal: Conflict log history table for Logical Replication To: Shlok Kyal , Dilip Kumar Cc: vignesh C , Amit Kapila , Nisha Moond , Peter Smith , Masahiko Sawada , Bharath Rupireddy , PostgreSQL Hackers , shveta malik Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 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-defined * extended statistics are not supported on these tables at present. */ 2) Assertion hit in alter_sub_conflict_log_dest(): set allow_system_table_mods=on create subscription sub1 connection '...' publication pub1 WITH(conflict_log_destination='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 = '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=ON. But I don't see a use case for allowing this. 3) I'm not sure whether the comments (at [1]) regarding the TRY-CATCH block were considered or perhaps overlooked. Please ignore this if you are already taking them into account. Doc-patch: 4) + direct user manipulation. Unlike pg_catalog, the + pg_catalog schema is not implicitly included in the + search path, so objects within it must be referenced explicitly or by + adjusting the search path. Second pg_catalog should be replaced with pg_conflict 5) + as the conflict schema) contains system managed + The pg_conflict schema that contains system-managed system managed or system-managed, we can use same at both the places. ~~ [1]: https://www.postgresql.org/message-id/CAJpy0uBSY7zTH%3D4TvAOS%3Dkj9vivBUc9NO%2BVp6KNw-Na9RiAsMg%40mail.gmail.com thanks Shveta