Date: Mon, 14 Oct 2024 16:59:37 -0400
From: Bruce Momjian <bruce@momjian.us>
To: px shi <spxlyy123@gmail.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: a litter question about mdunlinkfiletag function
Message-ID: <Zw2GOZlX3VSCI8nK@momjian.us>
References: <CAAccyYKeYNUCRR8JQ_wvWLF1Fu9CM5FMXQqtW96gFLH43phRHg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAAccyYKeYNUCRR8JQ_wvWLF1Fu9CM5FMXQqtW96gFLH43phRHg@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/Zw2GOZlX3VSCI8nK%40momjian.us>
Precedence: bulk

On Mon, Sep 30, 2024 at 10:43:17AM +0800, px shi wrote:
> Hi, hackers
> 
> When calculating the path, forknum is hardcoded as MAIN_FORKNUM:
> 
> /* Compute the path. */
> p = relpathperm(ftag->rnode, MAIN_FORKNUM);
> 
> 
> But since the ftag structure already contains forknum:
> 
> typedef struct FileTag
> {
> int16 handler; /* SyncRequestHandler value, saving space */
> int16 forknum; /* ForkNumber, saving space */
> RelFileNode rnode;
> uint32 segno;
> } FileTag;
> 
> 
> Wouldn’t it be more flexible to use the value from the ftag structure directly?

You will find other places where relpathperm() is called without having
a FileTag structure available, e.g. ReorderBufferProcessTXN().

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  When a patient asks the doctor, "Am I going to die?", he means 
  "Am I going to die soon?"