Re: [Proposal] Adding callback support for custom statistics kinds - Mailing list pgsql-hackers

From Chao Li
Subject Re: [Proposal] Adding callback support for custom statistics kinds
Date
Msg-id A5D8954F-2E20-4BF5-BA0E-79FDC06A632F@gmail.com
Whole thread Raw
In response to Re: [Proposal] Adding callback support for custom statistics kinds  (Sami Imseih <samimseih@gmail.com>)
Responses Re: [Proposal] Adding callback support for custom statistics kinds
List pgsql-hackers

> On Dec 9, 2025, at 03:09, Sami Imseih <samimseih@gmail.com> wrote:
>
>> Yes, thanks.  Structurally, this is better and more flexible than what
>> we had originally, and I have noticed that you have copied the
>> original files while adding more comments and renaming a bit things:
>> the structure of the functions was exactly the same.  Anyway, I have
>> worked on that for a good portion of the day, splitting the module
>> drop and the new module into two commits, and applied the result after
>> tweaking quite a few things in terms of names and comments (no
>> pgstat_*, a bit more "Var" and "Fixed", etc.), applying a much more
>> consistent set of names across the board for the functions and the
>> structures.  This cleanup part is moved out of the way now, so that
>> you ease the introduction of the next pieces you are proposing.
>
> Thanks for getting these committed!
>
> I rebased the custom callbacks patch in v5.
>
> One very minor thing from the earlier commits that I corrected here is
> the test for entry 2 after a clean restart.
>
> -is($result, "entry1|2", "variable-sized stats persist after clean restart");
> +is($result, "entry1|2|Test entry 1", "variable-sized stats persist
> after clean restart");
> +
> +$result = $node->safe_psql('postgres', q(select * from
> test_custom_stats_var_report('entry2')));
> +is($result, "entry2|3|Test entry 2", "variable-sized stats persist
> after clean restart");
> +
>
> --
> Sami Imseih
> Amazon Web Services (AWS)
> <v5-0001-Allow-cumulative-statistics-to-serialize-auxiliar.patch>

```
+                    if (kind_info->from_serialized_extra_stats)
+                    {
+                        if (!kind_info->from_serialized_extra_stats(&key, header, fpin))
+                        {
+                            elog(WARNING, "could not read extra stats for entry %u/%u/%" PRIu64,
+                                 key.kind, key.dboid, key.objid);
+                            goto error;
+                        }
+                    }
```

When deserialize failed, it goes to error. In the error clause, it calls pgstat_reset_after_failure(), so do we want to
giveextensions a chance to do some reset operations? If yes, then we can add a reset_after_failure() callback. 

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/







pgsql-hackers by date:

Previous
From: "Zhijie Hou (Fujitsu)"
Date:
Subject: RE: Newly created replication slot may be invalidated by checkpoint
Next
From: jian he
Date:
Subject: Re: CAST(... ON DEFAULT) - WIP build on top of Error-Safe User Functions