Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oE5Pi-0001ES-CV for pgsql-hackers@arkaria.postgresql.org; Wed, 20 Jul 2022 08:50:38 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oE5Ph-0000Tn-3x for pgsql-hackers@arkaria.postgresql.org; Wed, 20 Jul 2022 08:50:37 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oE5Pg-0000Te-PV for pgsql-hackers@lists.postgresql.org; Wed, 20 Jul 2022 08:50:36 +0000 Received: from mail-yb1-xb35.google.com ([2607:f8b0:4864:20::b35]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1oE5Pc-0002s4-Ff for pgsql-hackers@lists.postgresql.org; Wed, 20 Jul 2022 08:50:36 +0000 Received: by mail-yb1-xb35.google.com with SMTP id k85so28247737ybk.7 for ; Wed, 20 Jul 2022 01:50:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MZUWcuzErU4NquXp/Oh+GuCp7bHkP4sLapUwsRTPpTc=; b=HBk8vYI7FQjKtoQSFu+5Ewyvi8HKYqGecfkGYvYyFadsgmKSZFvvnkrXWnCVefoAtH CYfOncZXoMzBkXuIxyXlEvDurJhOtURXI5PW6y0Z8asEsls5eXdgLR2cJ8pkh21TpuFZ t+hzr5J4ebN76U/C0p6wyremTVdjYYV6zB9vRyYVqHDwx2H6SqGyt9XN9ZX/qiRsx4m2 TIi8oefPMMwP57IfyKHYwuSkiveWSjGlR6LI0TRrq+gRSNwueETdReLSZRepiabzD/ts tvADWFmdVX2gB11bGBrRuNYE6X/U5Nxa6wgt2Py/slHPtGbCEsEOgCUN1NM61Fob0Khi V08A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MZUWcuzErU4NquXp/Oh+GuCp7bHkP4sLapUwsRTPpTc=; b=eHVPf/CNql4RjB5rEEv15c/2tgumclDdqCkahw4xF/Y9SnSxvb63FyG05QYlyaqyFW Ac90fqTjMt3xh4GZZPJl3j0ipmRt6GimVm/fedo2CDjyILzw5QRXi7dhQYDSzQnE0vOc 11npVELKRjH6LjAaE2/G0jITKfWLRpm3AtoHV78Lg4tQa88EA6nE/ntTzEj/dYRGHb/p wT8WqyuglItqQhwi2GZDCuo9wjRpiqPrvXYrDL1hKoio0ykWde8q1xkgSS9VBfNzjpr3 X6jd3UrV7FssDMdvEojXT+/UJJSEO9MBYGUeL7IJyuM7tGZ8Nq4aDAr8W/neRsyTW+3v /CFQ== X-Gm-Message-State: AJIora/E8es3yV6akawq+EZY0g6GUoBGstfdZPd/szKFawDGBlPoH+jw Pb61rb2l1EzgcIHzBDdHq6OcXTDkQev0/ZtAKsI= X-Google-Smtp-Source: AGRyM1uLCbOakIqf8apGvGWDvqlSkZK3ctlov63aEdpwFnS9P6lMA6Tr/IdN0xwMkBtNCxN408OEfCPOy8wG2hsE+P4= X-Received: by 2002:a25:6f83:0:b0:668:b531:cefd with SMTP id k125-20020a256f83000000b00668b531cefdmr35280678ybc.495.1658307030457; Wed, 20 Jul 2022 01:50:30 -0700 (PDT) MIME-Version: 1.0 References: <20211008.165055.1621145185927268721.horikyota.ntt@gmail.com> <20220523.133323.444599955292141474.horikyota.ntt@gmail.com> In-Reply-To: From: Amit Kapila Date: Wed, 20 Jul 2022 14:20:18 +0530 Message-ID: Subject: Re: [BUG] Logical replication failure "ERROR: could not map filenode "base/13237/442428" to relation OID" with catalog modifying txns To: Masahiko Sawada Cc: "shiy.fnst@fujitsu.com" , Kyotaro Horiguchi , "Drouvot, Bertrand" , PostgreSQL Hackers , "Oh, Mike" Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Jul 20, 2022 at 1:28 PM Masahiko Sawada wrote: > > On Wed, Jul 20, 2022 at 2:19 PM Amit Kapila wrote: > > > > On Wed, Jul 20, 2022 at 9:01 AM Masahiko Sawada wrote: > > > > > Another idea would be to have functions, say > > > SnapBuildCommitTxnWithXInfo() and SnapBuildCommitTxn_ext(). The latter > > > does actual work of handling transaction commits and both > > > SnapBuildCommitTxn() and SnapBuildCommit() call > > > SnapBuildCommitTxnWithXInfo() with different arguments. > > > > > > > Do you want to say DecodeCommit() instead of SnapBuildCommit() in > > above para? > > I meant that we will call like DecodeCommit() -> > SnapBuildCommitTxnWithXInfo() -> SnapBuildCommitTxn_ext(has_invals = > true) -> SnapBuildXidHasCatalogChanges(has_invals = true) -> ... If > SnapBuildCommitTxn() gets called, it calls SnapBuildCommitTxn_ext() > with has_invals = false and behaves the same as before. > Okay, understood. This will work. > > Yet another idea could be to have another flag > > RBTXN_HAS_INVALS which will be set by DecodeCommit for top-level TXN. > > Then, we can retrieve it even for each of the subtxn's if and when > > required. > > Do you mean that when checking if the subtransaction has catalog > changes, we check if its top-level XID has this new flag? > Yes. > Why do we > need the new flag? > This is required if we don't want to introduce a new set of functions as you proposed above. I am not sure which one is better w.r.t back patching effort later but it seems to me using flag stuff would make future back patches easier if we make any changes in SnapBuildCommitTxn. -- With Regards, Amit Kapila.