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 1oJ33s-0005ap-W4 for pgsql-hackers@arkaria.postgresql.org; Wed, 03 Aug 2022 01:20:37 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oJ33r-0001Dh-Mc for pgsql-hackers@arkaria.postgresql.org; Wed, 03 Aug 2022 01:20:35 +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 1oJ33r-0001DY-Bw for pgsql-hackers@lists.postgresql.org; Wed, 03 Aug 2022 01:20:35 +0000 Received: from mail-pj1-x102d.google.com ([2607:f8b0:4864:20::102d]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1oJ33o-00073A-Lw for pgsql-hackers@lists.postgresql.org; Wed, 03 Aug 2022 01:20:34 +0000 Received: by mail-pj1-x102d.google.com with SMTP id q7-20020a17090a7a8700b001f300db8677so502141pjf.5 for ; Tue, 02 Aug 2022 18:20:32 -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=ZchS1exBkSGNXylgy3c78rBNcUPAm0qZL5Xp25LpWNw=; b=Usmo1aKLPkYtQYcZaMWAA/T+EOxSOEzrAaU+w9CSfFg+jZVX/gh6wJGM3hJcPCk0yI knjsK6yCivxNvDKxDTwKAJh5qCHQre+RiEBiFsotndzCtEOZcRekqiTYrutUunz2ErQ0 HCjPvXXw0YZLOH+qEnXc+6AmrhNWDkSqEqG9ETX7QVoQqoxZrAVgWQ/aM+1HXXhONpRR WgbsTQ8FQXWlcK69Ace8+axhdRHiNo7o+I/JcBScrSZTrFeDDLuwRJos0EDdxbJ+ftXq FogtAJ8c4l+z+jKvBmPMpSVQ2HTRhfyloMpDRJT4VrJ31ZF+fI5ap42HVvMtBEd+PP9L QUSw== 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=ZchS1exBkSGNXylgy3c78rBNcUPAm0qZL5Xp25LpWNw=; b=v8sPJCK5UWgQH0NAhX1Jb7bZR/U+/QP6ZGxQ4mfhhpcU/sAhx+WKdtqlnCqJQ+aMdp 9xz07xl+s18/NvgI8EkzXTPZiNBNnTYF1HZs1fVzJsFkmXO5I81BDPphDpZW5LHL4zaH eunZ/uReuirOlMxDCxAfQNAl2f/pHuzrVZTh5JJSE/Tjmuir6RC6V/CFV0FFWgTXtOri PrWFBe5mfvvThRvk/+2vH6A7+rYaSkGvUIM7DVqkFelAvCw63iAQQwLhCeuKXSTSHTi+ 5MyE1KD62vdHru0kHGM5ycI8dutdWFamrnPWVRY0ZIEyPTZTnfMv2utWKr9wg59ZXxvH 0ANA== X-Gm-Message-State: ACgBeo3U4xo7vdfY0zDc04izTSAnYKi/04DhkW+uu6TRxbp+KfU9o+V/ jaFjkWscWsxwsNQcM+r3Jcc= X-Google-Smtp-Source: AA6agR5U9+zUV/ocmn9xcUlWuohU/9ahbtNAWgzqIStI3BvdFOpZBwWJ3T0UtE2hhyORBFh9ir9NkA== X-Received: by 2002:a17:90b:4a91:b0:1f2:a67b:296f with SMTP id lp17-20020a17090b4a9100b001f2a67b296fmr2367597pjb.1.1659489630567; Tue, 02 Aug 2022 18:20:30 -0700 (PDT) Received: from localhost (KD036014041111.ppp-bb.dion.ne.jp. [36.14.41.111]) by smtp.gmail.com with ESMTPSA id f5-20020a170902684500b0016f1319d2a7sm322658pln.297.2022.08.02.18.20.28 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Tue, 02 Aug 2022 18:20:30 -0700 (PDT) Date: Wed, 03 Aug 2022 10:20:27 +0900 (JST) Message-Id: <20220803.102027.1786766955594381576.horikyota.ntt@gmail.com> To: amit.kapila16@gmail.com Cc: sawada.mshk@gmail.com, shiy.fnst@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: <20220802.153012.363912034520325077.horikyota.ntt@gmail.com> 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, 2 Aug 2022 13:54:43 +0530, Amit Kapila wrote in > On Tue, Aug 2, 2022 at 12:00 PM Kyotaro Horiguchi > wrote: > > > > + { > > + int save_errno = errno; > > + > > + CloseTransientFile(fd); > > + > > + if (readBytes < 0) > > + { > > + errno = save_errno; > > + ereport(ERROR, > > > > Do we need the CloseTransientFile(fd) there? This call requires errno > > to be remembered but anyway OpenTransientFile'd files are to be close > > at transaction end. Actually CloseTransientFile() is not called > > before error'ing-out at error in other places. .. > We just moved it to a separate function as the same code is being > duplicated to multiple places. There are code paths that doesn't CloseTransientFile() explicitly, too. If there were no need of save_errno there, that'd be fine. But otherwise I guess we prefer to let the orphan fds closed by ERROR and I don't think we need to preserve the less-preferred code pattern (if we actually prefer not to have the explicit call). regards. -- Kyotaro Horiguchi NTT Open Source Software Center