Re: Reconcile stats in find_tabstat_entry() and get rid of PgStat_BackendFunctionEntry

From: "Drouvot, Bertrand" <bertranddrouvot(dot)pg(at)gmail(dot)com>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: andres(at)anarazel(dot)de, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Reconcile stats in find_tabstat_entry() and get rid of PgStat_BackendFunctionEntry
Date: 2023-02-14 14:43:26
Message-ID: 9262b2a9-6785-1f83-bf7f-7fcf90c2c113@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2/14/23 7:11 AM, Kyotaro Horiguchi wrote:
>
> Isn't it ignoring the second call to pgstat_fetch_pending_entry?
>

Oh right, my bad (the issue has been introduced in V2).
Fixed in V4.

> I thought that we might be able to return entry_ref->pending since the
> callers don't call pfree on the returned pointer, but it is not great
> that we don't inform the callers if the returned memory can be safely
> pfreed or not.
>
> Thus what I have in mind is the following.
>
>> if (!entry_ref)
>> + {
>> entry_ref = pgstat_fetch_pending_entry(PGSTAT_KIND_RELATION,
>> InvalidOid, rel_id);
>> + if (!entry_ref)
>> + return NULL;
>> + }

LGTM, done that way in V4.

>
>
>
>>> So, since we want to hide the internal from pgstatfuncs, the
>>> additional flag should be gone.
>>
>> I think there is pros and cons for both but I don't have a strong
>> opinion about that.
>>
>> So also proposing V3 attached without the flag in case this is the
>> preferred approach.
>
> That part looks good to me.
>

Thanks!

Regards,

--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

Attachment Content-Type Size
v4-0001-find_tabstat_entry_recon.patch text/plain 3.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Karina Litskevich 2023-02-14 14:49:27 Possible false valgrind error reports
Previous Message Dag Lem 2023-02-14 14:27:21 Re: daitch_mokotoff module