Re: Add pg_walinspect function with block info columns
От | Kyotaro Horiguchi |
---|---|
Тема | Re: Add pg_walinspect function with block info columns |
Дата | |
Msg-id | 20230309.094612.334241012776602242.horikyota.ntt@gmail.com обсуждение исходный текст |
Ответ на | Re: Add pg_walinspect function with block info columns (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>) |
Ответы |
Re: Add pg_walinspect function with block info columns
|
Список | 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 по дате отправления: