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 1oGsdw-0006oH-GX for pgsql-hackers@arkaria.postgresql.org; Thu, 28 Jul 2022 01:48:52 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oGsdv-00031Y-C7 for pgsql-hackers@arkaria.postgresql.org; Thu, 28 Jul 2022 01:48:51 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oGsdv-00031P-2o for pgsql-hackers@lists.postgresql.org; Thu, 28 Jul 2022 01:48:51 +0000 Received: from mail-pl1-x62d.google.com ([2607:f8b0:4864:20::62d]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1oGsds-0006f3-Ow for pgsql-hackers@lists.postgresql.org; Thu, 28 Jul 2022 01:48:50 +0000 Received: by mail-pl1-x62d.google.com with SMTP id x7so527353pll.7 for ; Wed, 27 Jul 2022 18:48:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=KApzrPhpDdXtg0kdd9M/F8i4vaEgYu6qNlBCVAVFNe0=; b=Bwb/1CQg0pqXsf+0c0k1AOtm7ce8In0JULqPJjssxxJriEBppJso87kHjArx/yid9g hIf4UjUKgbaVaNodGY6R3EWWb3gBCcFrn2S4Y6EFwrNvHahYg6XyTorRmYJ8Uuy/0lpB SeYps7if6nbHmcfsMtEgmsWcPgiDrKpbisbEom1w6mNSKVmyMmaOGfc6Z6tWMMfYYQg9 zPazksVSMFJfkik99+2GieDiM34oKISMwEmJfQ2l1BAzDRgQn9eAWT7+DECXBTfJcYaa ESvAJKfu6xc8MsyOgeuWpIwC//63B6Fta+TWYWwf/+4oDUowYeHFh/06WBGeeLKT+coy fSZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=KApzrPhpDdXtg0kdd9M/F8i4vaEgYu6qNlBCVAVFNe0=; b=toQNH9sDcfyAk2h2WttlFgTymD8Z6nRHOzslLlvWdDl8SmsD9mbMytZ2BaKXQhRj0x P6Eam5Hd9yKvQJNRyLd0mY5y5gU93oA0l8Gca00sdSUgDEzYynXa8Al/32rqkcBAMF9k Yv5zDUfioVgO8XkfLgYfqhXjRNTRiFmopwINfRLR1Xc3YZDGVLEm7Vs7x+NMtJtXpdeV WmnHR0qo/jKntSmPfgdMX6nN4lNigkIxhWQthdGUM82x4eh1ofeRPlQYP3ZgZzge4kRu S3p3xyuUUCPbQMc1RZ9ImTuUCkn4GJauJGvOghD0IAa73VS5nowVROxRVJ4kdV68pIS2 kQSA== X-Gm-Message-State: AJIora9Mg3cZCJSC6pi6GEuc5dT73Ctnn+AYo8CbbCdhC7BOIEIYKWP3 N2tGdQsfqcA8mF3Hy7Q4LLJnrp/FOow4V224umo= X-Google-Smtp-Source: AGRyM1uIhBHi/x8F1AaxTm9N8XiEdErYoUAkSJT5NsiME7JMcbhajDn/wunUGoNXrBha4nL3cCbt/OElbF5mnU0Rp4A= X-Received: by 2002:a17:902:6b0a:b0:16c:38eb:b516 with SMTP id o10-20020a1709026b0a00b0016c38ebb516mr24101144plk.15.1658972927552; Wed, 27 Jul 2022 18:48:47 -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: Masahiko Sawada Date: Thu, 28 Jul 2022 10:48:11 +0900 Message-ID: Subject: Re: [BUG] Logical replication failure "ERROR: could not map filenode "base/13237/442428" to relation OID" with catalog modifying txns To: Amit Kapila 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 27, 2022 at 8:33 PM Amit Kapila wrote: > > On Mon, Jul 25, 2022 at 11:26 AM Masahiko Sawada wrote: > > > > On Mon, Jul 25, 2022 at 10:45 AM Masahiko Sawada wrote: > > > > I've attached the patch for REl15 that I forgot. > > > > I feel the place to remember running xacts information in > SnapBuildProcessRunningXacts is not appropriate. Because in cases > where there are no running xacts or when xl_running_xact is old enough > that we can't use it, we don't need that information. I feel we need > it only when we have to reuse the already serialized snapshot, so, > won't it be better to initialize at that place in > SnapBuildFindSnapshot()? Good point, agreed. > I have changed accordingly in the attached > and apart from that slightly modified the comments and commit message. > Do let me know what you think of the attached? It would be better to remember the initial running xacts after SnapBuildRestore() returns true? Because otherwise, we could end up allocating InitialRunningXacts multiple times while leaking the old ones if there are no serialized snapshots that we are interested in. --- + if (builder->state == SNAPBUILD_START) + { + int nxacts = running->subxcnt + running->xcnt; + Size sz = sizeof(TransactionId) * nxacts; + + NInitialRunningXacts = nxacts; + InitialRunningXacts = MemoryContextAlloc(builder->context, sz); + memcpy(InitialRunningXacts, running->xids, sz); + qsort(InitialRunningXacts, nxacts, sizeof(TransactionId), xidComparator); + } We should allocate the memory for InitialRunningXacts only when (running->subxcnt + running->xcnt) > 0. Regards, -- Masahiko Sawada EDB: https://www.enterprisedb.com/