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

Поиск
Список
Период
Сортировка
От Drouvot, Bertrand
Тема Re: Reconcile stats in find_tabstat_entry() and get rid of PgStat_BackendFunctionEntry
Дата
Msg-id 9262b2a9-6785-1f83-bf7f-7fcf90c2c113@gmail.com
обсуждение исходный текст
Ответ на Re: Reconcile stats in find_tabstat_entry() and get rid of PgStat_BackendFunctionEntry  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Ответы Re: Reconcile stats in find_tabstat_entry() and get rid of PgStat_BackendFunctionEntry  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Список 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
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Dag Lem
Дата:
Сообщение: Re: daitch_mokotoff module
Следующее
От: Karina Litskevich
Дата:
Сообщение: Possible false valgrind error reports