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