Re: Add pg_walinspect function with block info columns - Mailing list pgsql-hackers

From Kyotaro Horiguchi
Subject Re: Add pg_walinspect function with block info columns
Date
Msg-id 20230309.094612.334241012776602242.horikyota.ntt@gmail.com
Whole thread Raw
In response to Re: Add pg_walinspect function with block info columns  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Responses Re: Add pg_walinspect function with block info columns  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
At Wed, 8 Mar 2023 20:18:06 +0530, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> wrote in 
> On Wed, Mar 8, 2023 at 4:23 PM Michael Paquier <michael@paquier.xyz> wrote:
> >
> > On Wed, Mar 08, 2023 at 04:01:56PM +0530, Bharath Rupireddy wrote:
> > > I understand that performance is critical here but we need to ensure
> > > memory is used wisely. Therefore, I'd still vote to free at least the
> > > major contributors here, that is, pfree(raw_data);, pfree(raw_page);
> > > and pfree(flags); right after they are done using. I'm sure pfree()s
> > > don't hurt more than resetting memory context for every block_id.
> >
> > Okay by me to have intermediate pfrees between each block scanned if
> > you feel strongly about it.
> 
> Thanks. Attached v4 with that change.

Although I'm not strongly opposed to pfreeing them, I'm not sure I
like the way the patch frees them.  The life times of all of raw_data,
raw_page and flags are within a block.  They can be freed
unconditionally after they are actually used and the scope of the
pointer variables can be properly narowed.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: meson vs make: missing/inconsistent ENV
Next
From: Thomas Munro
Date:
Subject: Re: Add error functions: erf() and erfc()