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 1wTOJL-000Unm-1R for pgsql-hackers@arkaria.postgresql.org; Sat, 30 May 2026 18:21:27 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wTOJJ-006FIl-2g for pgsql-hackers@arkaria.postgresql.org; Sat, 30 May 2026 18:21:26 +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 1wTOJJ-006FId-1W for pgsql-hackers@lists.postgresql.org; Sat, 30 May 2026 18:21:25 +0000 Received: from mail-lf1-x130.google.com ([2a00:1450:4864:20::130]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wTOJH-00000000LSW-1oys for pgsql-hackers@lists.postgresql.org; Sat, 30 May 2026 18:21:25 +0000 Received: by mail-lf1-x130.google.com with SMTP id 2adb3069b0e04-5aa2c25c632so10564482e87.1 for ; Sat, 30 May 2026 11:21:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1780165282; cv=none; d=google.com; s=arc-20240605; b=K+JWofS0y2Xw+nMpQHJFAfzpc6iLTGfXVrk8efZ8iv/+4Yu093Xq64i+pC8sKEh9/j N/yDH2F5BVPS3QxCG2GShibgthVXOYytsL/akeu+OghstdKFmAkHSabPCkQhcy1rTWKZ a4cxX21SwBOPuwGRc6qNM8wR5Dd7WRDQ+8rkHrpRoe86CeRiNbEriyhyYmOqRu1mamYf v7sXmpc43ZAGdNhwPnlNW0pnee93F/cjjINi0p54jmzzppCu2kDovOLRP5hWohsg3zrt 7cQ1e23vj1JyDTbJapYTsErkC0szZXxU3D2/5xthNhGB0vHvOM298G2aoNY5pI+90r2U IimA== 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=gWbD/9jz0on3HIY9S1k8JOSy85J1+rtTqPIszmpGuhw=; fh=GnjVqZScpZ4zlch4O0w6nwdvBSBN3alzGhQOPhIKjeE=; b=ONcNXc1txK/djcE0panM7rzu7nG9q/oGj8sqe2MBEQQ5EyTUFI/l5EUrdHUM8RIQgq bQxunYjtIeDLcJ7BlSUMOn6V2ASYQMarh/M/Kvg9RDkZli3DcbG03gSoRRYOHyyMSeTn mopfg+MTX5ICguBN8rhOxxfthi+nLimdQbURlg2zlw2+VKgAUEWBfJCPZW3UroXFcERq U5QGiadoyNC7Ih3A4V3ishh/Sxt4xR8u65AzLatYVxR4YIxqgUGMAeMGd1pylyPVwRih gtzs/Sjr2sDVbLxDTmjVwvmfEDh6x2zv/H18NTFXGN0MqO1EDnmVm8ReMwPCekA55eS5 asnQ==; 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=1780165282; x=1780770082; 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=gWbD/9jz0on3HIY9S1k8JOSy85J1+rtTqPIszmpGuhw=; b=rFGwaP25WIxa+j3q48ErBZ7FZU/3kGUqKmftAXA3bmw73AHcItbSpWi1yB/98HL1PY 4Zpdtr0rkridW6MdrpgszTHmTs8N2/DBlKX2O2ZtX3T24imqLdSJKYM7SGV57R8ozp0b 8du66it1Bo9RkYskakIWkic+yTBnjpE3mp4JwZvs9rWTKgDOWZM3iW7dlIMX/rKbvTYz AOyVimaN+vH3mWec5TDejA/CELSBE9YtVzrmdmEBhRG5ZTM80YNU/pfksxw2fRi/4qoV br3XxZQssp0e4YQywLa6tqxeE0ZfnEJHtn0W/KPoA69PLTmUMr5pB6R+UsVyJEPbdewn xttA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780165282; x=1780770082; 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=gWbD/9jz0on3HIY9S1k8JOSy85J1+rtTqPIszmpGuhw=; b=rfEMhOoduquX9Arh+ueDHfIx+MDhkRj0OT7uGqGpS27VXyCK83J2/sWTiek8Z7bRks 7gkm9Q1K2qR7P5cwJlhpyhIxPZKHkstQ2zC5A9Jq/nTTlSzMaEqZERgKm3L9C59UjHGz Uz1JIFjBpbuXTaJp/Oab5Kyy2qCkLiC9Sg06IhK3s1tPACWMIp65iXWMHFO9Je9N8Ght 06xUYA2QgCPOazbuT8Rom0KWbtz0ZtBsXjYuCLnG6yRPD5Wwkv438w9Dt9t4xHtdE6qb AgOkAHS5D4dQ4b82UdN9jBiKraC0aiHItp0zWlV1RYuCNCIYJo91a0EKdyMIoSpDs1/S Pnuw== X-Forwarded-Encrypted: i=1; AFNElJ+3TqGJ9d8XsM+qX5ErNLFthwc2IaKJ8HiHAYUhO/MzUgBKLWQCW/ZjJUPW8eBK6hN4tcsq1j2LCA/HGMrx@lists.postgresql.org X-Gm-Message-State: AOJu0YxU8WFVSo8Z4c1FB1Xy+2E1cKViHRQneKAtqHJVBc3/IRl1m4d8 tF7FpCu5p2OX9NisKMAkJTgDJt79hb/9E4BJsm3ow2rMnkIPnUItOcFP9v2IFshmy5EcqzwmOmu tjfXfUh/IOdIjqp2CLnmIhq+XKUTyAiQ= X-Gm-Gg: Acq92OFNr8c30uH5RvSqPE0kOK8nRDtlIA6xIbXdR3myfnOVy+LIKJlf1SifuaMxphy LIaW5yLEBFiDKeuYQ+8BTIEEkRKKRCysjMophHjmSzF4IkbH0Fg8sPHGpbkHikxb1zBe1ZDq4G/ k+E9LAL4aMSh3MJXRKs1o927u5PQrJ2B1ujSMA70SkZfNFBSX+ESSzPcvLhPQvnnjrAqKUm6q1R 4rfhMg9PMnyJPTUsyRqRA9YCXpSJsp0Yawmyg2q1JbNrNz7RDC5I3ZlIP8LHA44cFbEQB4vLLWp 9wDFmpDuMsG0CzSRhNwBFGwdfcWQ8xVgBRz6HGO1gp+w6J6OkYclAzO4xWQtxpDFAVb0kqxHNr3 XhicBMYQ6jGUvEv9avks= X-Received: by 2002:a05:6512:ac8:b0:5aa:62ca:3128 with SMTP id 2adb3069b0e04-5aa62ca31a1mr973505e87.14.1780165282122; Sat, 30 May 2026 11:21:22 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Amit Kapila Date: Sat, 30 May 2026 11:21:10 -0700 X-Gm-Features: AVHnY4JtyHQSWtehN-rfs_Yepl5Nqj3KYAlMlTfDiWuNY_RQYbWbZSd1JUnNupQ Message-ID: Subject: Re: Proposal: Conflict log history table for Logical Replication To: Dilip Kumar Cc: Nisha Moond , vignesh C , 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 Fri, May 29, 2026 at 3:07=E2=80=AFPM Dilip Kumar = wrote: > > On Sat, May 30, 2026 at 3:24=E2=80=AFAM Dilip Kumar wrote: > > After putting more thought, I think instead of executing a three-step > process i.e. inserting the pg_subscription tuple, creating the table > with its dependency, and then going back to update the tuple with the > new relation ID, it is much cleaner to do it linearly, i.e. we should > create the conflict log table first to get its OID, insert the > subscription tuple pre-populated with that ID, and then record the > dependency. This achieves the exact same state in a single direct > sequence without the redundant catalog update within the same command. > I agree with that code we would have to keep the record dependency > code in CreateSubscription and AlterSubscription functions, but after > putting more thought I think in thoese function we are already > recording subscription dependencies with other object so wouldn't it > be more natural to add this depednecy as well at the same place? > It makes sense to me and anyway for serverid also we are creating dependency after creation of subscription, so your solution looks good to me. One minor suggestion related to this changes: + if (CONFLICTS_LOGGED_TO_TABLE(opts.conflictlogdest)) + { + ObjectAddress clt; + + ObjectAddressSet(clt, RelationRelationId, logrelid); + recordDependencyOn(&clt, &myself, DEPENDENCY_INTERNAL); + } Let's name clt as cltaddr or cltobj to make it consistent with naming at some other similar places in code. Change this at both places where we use this code. > Anyway I am ready to change that if we have strong opinion against > this approach. > > Here is the updated patch and changes are > 1. 0003 and 0004 are merged on 0001 > 2. Merged Amit's v41_amit_1.patch.txt to 0002 > 3. Fix the dependency order issue (i.e. create dependency after > inserting subscription tuple) and merged in 0002 > > Open Items: > 1. Need to create toast table for CLT after testing with larger JSON row > 2. Fixed review comments of Shveta on 0004 and 0005 > 3. Rebase Vignesh's patch of > "v41-0007-Preserve-conflict-log-destination-and-subscripti" I think we > can do that once we have concensus on whether to create conflict log > table first or insert the subscription row first as based on this > change we would have to rebase this patch again. > 4. Once we rebase > "v41-0007-Preserve-conflict-log-destination-and-subscripti" after > dependency order consensus I would rebase doc patch and \dRs+ change > patch of Vignesh. > I see that my second comment in email [1] and another comment in email [2] are still not answered and are neither listed in open items. [1] - https://www.postgresql.org/message-id/CAA4eK1%2BzdaLF7%3DAVKd8xNGTuvP= vn8BYSxHfnLZd7whWZ%2Bv3B-Q%40mail.gmail.com [2] - https://www.postgresql.org/message-id/CAA4eK1K6tVUmKY-yqKgTX00yrSVAdS= ZN4Ao761JEXdtQkAYT4g%40mail.gmail.com --=20 With Regards, Amit Kapila.