Re: Add pg_walinspect function with block info columns

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: bharath(dot)rupireddyforpostgres(at)gmail(dot)com
Cc: michael(at)paquier(dot)xyz, boekewurm+postgres(at)gmail(dot)com, melanieplageman(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org, pg(at)bowt(dot)ie
Subject: Re: Add pg_walinspect function with block info columns
Date: 2023-03-09 00:46:12
Message-ID: 20230309.094612.334241012776602242.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Wed, 8 Mar 2023 20:18:06 +0530, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote in
> On Wed, Mar 8, 2023 at 4:23 PM Michael Paquier <michael(at)paquier(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2023-03-09 01:02:46 Re: Add error functions: erf() and erfc()
Previous Message Michael Paquier 2023-03-09 00:36:52 Re: meson vs make: missing/inconsistent ENV