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
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 |