Thread: Re: Add a write_to_file member to PgStat_KindInfo

Hi,

Thank you for working on this!

On Wed, 20 Nov 2024 at 17:05, Bertrand Drouvot
<bertranddrouvot.pg@gmail.com> wrote:
>
> Hi hackers,
>
> Working on [1] produced the need to give to the statistics the ability to
> decide whether or not they want to be written to the file on disk.
>
> Indeed, there is no need to write the per backend I/O stats to disk (no point to
> see stats for backends that do not exist anymore after a re-start), so $SUBJECT.

I think this is a good idea. +1 for the $SUBJECT.

> This new member could also be useful for custom statistics, so creating this
> dedicated thread.
>
> The attached patch also adds a test in the fixed injection points statistics.
> It does not add one for the variable injection points statistics as I think adding
> one test is enough (the code changes are simple enough).

There are duplicated codes in the injection_stats_fixed.c file. Do you
think that 'modifying existing functions to take an argument to
differentiate whether the kind is default or no-write' would be
better?

--
Regards,
Nazir Bilal Yavuz
Microsoft

Hi,

On Thu, 21 Nov 2024 at 09:32, Bertrand Drouvot
<bertranddrouvot.pg@gmail.com> wrote:
> That was in fact the main reason why I added this test. But well, just
> adding the "write_to_file" in the injection test is enough to "show" that this
> member does exist. So I'm fine with v3.

I think that the changes below (write_to_file checks) should come
after the assertion checks. Otherwise, they could mask some problems.

=== 1
-        if (!info || !info->fixed_amount)
+        /* skip if not fixed or this kind does not want to write to the file */
+        if (!info || !info->fixed_amount || !info->write_to_file)
             continue;

         if (pgstat_is_kind_builtin(kind))
            Assert(info->snapshot_ctl_off != 0);

=== 2
         kind_info = pgstat_get_kind_info(ps->key.kind);

+        /* skip if this kind does not want to write to the file */
+        if (!kind_info->write_to_file)
+            continue;
+
         /* if not dropped the valid-entry refcount should exist */
         Assert(pg_atomic_read_u32(&ps->refcount) > 0);
===

--
Regards,
Nazir Bilal Yavuz
Microsoft

Hi,

On Thu, Nov 21, 2024 at 04:26:47PM +0900, Michael Paquier wrote:
> On Thu, Nov 21, 2024 at 06:32:03AM +0000, Bertrand Drouvot wrote:
> > That was in fact the main reason why I added this test. But well, just 
> > adding the "write_to_file" in the injection test is enough to "show" that this
> > member does exist. So I'm fine with v3.
> 
> Plus/minus some tweaks in the wordings (like a s/stat /stats /),

I think the singular was ok here, but v4 (just shared up-thread) uses your
proposal.

Regards,

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

Hi,

Thanks for patch. I have tested both patches and they work as per design.

My +1 for v1, it is much cleaner approach and has properly named 
functions whereas in v2 it is not.

Injection points is documented, if so, doc patch is missing.

Regards,
Yogesh

On 11/20/24 12:13, Bertrand Drouvot wrote:
> Hi,
>
> On Wed, Nov 20, 2024 at 05:45:55PM +0300, Nazir Bilal Yavuz wrote:
>> I think this is a good idea. +1 for the $SUBJECT.
> Thanks for looking at it!
>
>> There are duplicated codes in the injection_stats_fixed.c file. Do you
>> think that 'modifying existing functions to take an argument to
>> differentiate whether the kind is default or no-write' would be
>> better?
> Some of the new functions are callbacks so we don't have the control on the
> parameters list that the core is expecting.
>
> It remains:
>
> pgstat_register_inj_fixed_no_write()
> pgstat_report_inj_fixed_no_write()
> injection_points_stats_fixed_no_write()
>
> for which I think we could add an extra "write_to_file" argument on their original
> counterparts.
>
> Not sure how many code reduction we would get, so out of curiosity I did the
> exercice in v2 attached and that gives us:
>
> v1:
> 8 files changed, 211 insertions(+), 2 deletions(-)
>
> v2:
> 8 files changed, 152 insertions(+), 22 deletions(-)
>
> I don't have a strong opinion for this particular case here (I think the code
> is harder to read but yeah there is some code reduction): so I'm fine with
> v2 too.
>
> Regards,
>