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 1oDi6f-0005jY-0j for pgsql-hackers@arkaria.postgresql.org; Tue, 19 Jul 2022 07:57:25 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oDi6d-0004UE-6A for pgsql-hackers@arkaria.postgresql.org; Tue, 19 Jul 2022 07:57:23 +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 1oDi6c-0004Tx-R7 for pgsql-hackers@lists.postgresql.org; Tue, 19 Jul 2022 07:57:22 +0000 Received: from mail-pj1-x102b.google.com ([2607:f8b0:4864:20::102b]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1oDi6a-0006U3-AU for pgsql-hackers@lists.postgresql.org; Tue, 19 Jul 2022 07:57:22 +0000 Received: by mail-pj1-x102b.google.com with SMTP id z12-20020a17090a7b8c00b001ef84000b8bso20530827pjc.1 for ; Tue, 19 Jul 2022 00:57:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:message-id:to:cc:subject:from:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=/+kWDPfPykaQnhTSmxm8UC7aZLMJQFmT7XAgvh4VB4M=; b=Jf52RfwG+L+Gf6zHVIecUI7qbQcfWJwFoBsLkkZaxutAh2Zk19SL6K4VxVsXdjbSI5 IPB52YctA/X+X8C7QK74lYm/XoJRFFZ+nFBfWADWeX2sA+ts/Y6I6gUMvNXtIVXnv4At scKZ6xi4h94gmhM5Vb7fMYYDaijmtgOCkW6vxaPY9T5DWLWksjxVCLNI+OYRjviFHRtO LGdhEN2wHO9wVEuc3u3zeTMszpapgx/d59urLadzT0A54//IHVTiBDXEfkFRqAdk8J4L M8p8o2YIauuAtaGMMFE1eVV9O9ZWduftbkxmh+0awshn4z1nUtU08Nt+NCzTdJldhl3D vFJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:message-id:to:cc:subject:from:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=/+kWDPfPykaQnhTSmxm8UC7aZLMJQFmT7XAgvh4VB4M=; b=XG1gpNehG96s1siQQrCYrNpOhpksLvJKZquOzF1XFRevJNFDJHBpzSipcew1R9Xna7 0IzfSwhY388fCbqP94Fd70z0pN9w3WuIyiGCQCpasdhlfiQNVz0ha14nTIQMzYj0QanW ijK8Y4q9bPEkeDC8NrZ6Yo3OL2dQrfRp/GT+r1FYIyuMBKNIOhgeywWt4uXQFNR4al2Y +YOrvF5rJelY2JOghTIJ8mVa6H8S7L0QbBdAsrQNegwd7g66PrwgPjvDBCZo3Pbjbx7i lV7W328Cp5pDeywreZgFAqcrqiAFJFD+eq6U1WXRu5ECtyu+wecgym+l0Z/3Sz/QNx3t G6qg== X-Gm-Message-State: AJIora/NVx9pQloL6xjvPJC58V2BL3u6afu5QXt8qh6TNKYaLSoi9W00 qDI/czwT8Spg6WZjc1mQs7w= X-Google-Smtp-Source: AGRyM1tUc2OUBWGl3nPZS3lQXlhpZloNCp7Xm0sZbXqY3PSYIPAaPy4zitppHTnJ6nSi/i8JEKrTJQ== X-Received: by 2002:a17:903:1208:b0:16b:81f6:e992 with SMTP id l8-20020a170903120800b0016b81f6e992mr32759703plh.55.1658217438154; Tue, 19 Jul 2022 00:57:18 -0700 (PDT) Received: from localhost (KD036014041111.ppp-bb.dion.ne.jp. [36.14.41.111]) by smtp.gmail.com with ESMTPSA id u3-20020a170902e80300b00166304d081bsm11018417plg.24.2022.07.19.00.57.15 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Tue, 19 Jul 2022 00:57:17 -0700 (PDT) Date: Tue, 19 Jul 2022 16:57:14 +0900 (JST) Message-Id: <20220719.165714.766068228275757655.horikyota.ntt@gmail.com> To: sawada.mshk@gmail.com Cc: amit.kapila16@gmail.com, osumi.takamichi@fujitsu.com, bdrouvot@amazon.com, pgsql-hackers@lists.postgresql.org, minsoo@amazon.com Subject: Re: [BUG] Logical replication failure "ERROR: could not map filenode "base/13237/442428" to relation OID" with catalog modifying txns From: Kyotaro Horiguchi In-Reply-To: References: User-Agent: Mew version 6.8 on Emacs 26.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk At Tue, 19 Jul 2022 16:02:26 +0900, Masahiko Sawada wrote in > On Tue, Jul 19, 2022 at 1:47 PM Amit Kapila wrote: > > Good work. I wonder without comments this may create a problem in the > > future. OTOH, I don't see adding a check "catchange.xcnt > 0" before > > freeing the memory any less robust. Also, for consistency, we can use > > a similar check based on xcnt in the SnapBuildRestore to free the > > memory in the below code: > > + /* set catalog modifying transactions */ > > + if (builder->catchange.xip) > > + pfree(builder->catchange.xip); > > I would hesitate to add comments about preventing the particular > optimization. I think we do null-pointer-check-then-pfree many place. > It seems to me that checking the array length before memcpy is more > natural than checking both the array length and the array existence > before pfree. Anyway according to commit message of 46ab07ffda, POSIX forbits memcpy(NULL, NULL, 0). It seems to me that it is the cause of the false (or over) optimization. So if we add some comment, it would be for memcpy, not pfree.. regards. -- Kyotaro Horiguchi NTT Open Source Software Center