Horton

Thread

Commits

  1. Adjust some comments about structure properties in pg_stat.h

  1. Fix comments related to pending statistics

    Bertrand Drouvot <bertranddrouvot.pg@gmail.com> — 2024-12-10T14:16:14Z

    Hi hackers,

while working on [1], I came across 2 comments in pgstat.h that I think are 
not correct.

1. One linked to PgStat_TableCounts pending stats, mentioning the use of
memcmp() against zeroes to detect whether there are any stats updates to apply.

This is not true anymore as of 07e9e28b56.

2. One linked to PgStat_FunctionCounts pending stats, mentioning the use of
memcmp() against zeroes to detect whether there are any pending stats: I think
it has never been the case.

Please find attached a patch to fix those comments.

[1]: https://www.postgresql.org/message-id/flat/ZlGYokUIlERemvpB%40ip-10-97-1-34.eu-west-3.compute.internal

Regards,

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

  2. Re: Fix comments related to pending statistics

    Michael Paquier <michael@paquier.xyz> — 2024-12-11T05:56:08Z

    On Tue, Dec 10, 2024 at 02:16:14PM +0000, Bertrand Drouvot wrote:
> 1. One linked to PgStat_TableCounts pending stats, mentioning the use of
> memcmp() against zeroes to detect whether there are any stats updates to apply.
> 
> This is not true anymore as of 07e9e28b56.

Oops, you're right.  The comment has missed the memo about this
mention to memcpy().

> 
> 2. One linked to PgStat_FunctionCounts pending stats, mentioning the use of
> memcmp() against zeroes to detect whether there are any pending stats: I think
> it has never been the case.

  * PgStat_FunctionCounts	The actual per-function counts kept by a backend
  *
- * This struct should contain only actual event counters, because we memcmp
- * it against zeroes to detect whether there are any pending stats.
+ * This struct should contain only actual event counters, because pending stats
+ * always has non-zero content.

pgstat_function_flush_cb() in pgstat_function.c says since
5891c7a8ed8f, so that seems like a remnant from the original patch
that has introduced this inconsistency across its reviews:
"/* localent always has non-zero content */"

Your suggestion does not look completely right to me.  There is
nothing preventing us from using something else than event counters
since we don't use memcpy() and there is no comparison work, no?  It
seems to me that we could remove the entire sentence instead.
--
Michael

  3. Re: Fix comments related to pending statistics

    Bertrand Drouvot <bertranddrouvot.pg@gmail.com> — 2024-12-11T07:32:38Z

    Hi,

On Wed, Dec 11, 2024 at 02:56:08PM +0900, Michael Paquier wrote:
> On Tue, Dec 10, 2024 at 02:16:14PM +0000, Bertrand Drouvot wrote:
> > 
> > 2. One linked to PgStat_FunctionCounts pending stats, mentioning the use of
> > memcmp() against zeroes to detect whether there are any pending stats: I think
> > it has never been the case.
> 
>   * PgStat_FunctionCounts	The actual per-function counts kept by a backend
>   *
> - * This struct should contain only actual event counters, because we memcmp
> - * it against zeroes to detect whether there are any pending stats.
> + * This struct should contain only actual event counters, because pending stats
> + * always has non-zero content.
> 
> pgstat_function_flush_cb() in pgstat_function.c says since
> 5891c7a8ed8f, so that seems like a remnant from the original patch
> that has introduced this inconsistency across its reviews:
> "/* localent always has non-zero content */"

Thanks for looking at it!

Yeah and same in pgstat_subscription_flush_cb(). 

> Your suggestion does not look completely right to me.  There is
> nothing preventing us from using something else than event counters
> since we don't use memcpy() and there is no comparison work, no?  It
> seems to me that we could remove the entire sentence instead.

Do you mean also remove the comments in pgstat_function_flush_cb() and
pgstat_subscription_flush_cb()? Those comments look fine to me given
the places where those pending entries are created meaning in
pgstat_init_function_usage() for the functions and pgstat_report_subscription_error()
and pgstat_report_subscription_conflict() for the subscriptions.

Regards,

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

  4. Re: Fix comments related to pending statistics

    Michael Paquier <michael@paquier.xyz> — 2024-12-12T00:20:15Z

    On Wed, Dec 11, 2024 at 07:32:38AM +0000, Bertrand Drouvot wrote:
> On Wed, Dec 11, 2024 at 02:56:08PM +0900, Michael Paquier wrote:
>> Your suggestion does not look completely right to me.  There is
>> nothing preventing us from using something else than event counters
>> since we don't use memcpy() and there is no comparison work, no?  It
>> seems to me that we could remove the entire sentence instead.
> 
> Do you mean also remove the comments in pgstat_function_flush_cb() and
> pgstat_subscription_flush_cb()? Those comments look fine to me given
> the places where those pending entries are created meaning in
> pgstat_init_function_usage() for the functions and pgstat_report_subscription_error()
> and pgstat_report_subscription_conflict() for the subscriptions.

My apologies for the confusion.  I see no problem with the existing
comments in pgstat_subscription_flush_cb() and
pgstat_function_flush_cb() because they still apply.  The comment in
pgstat.h 

The only thing we should do here is to remove the comment for
PgStat_FunctionCounts because we could add pointers or something else
than plain counters in this structure, and fix the comment of
PgStat_TableCounts in the lines of what you are suggesting.
--
Michael

  5. Re: Fix comments related to pending statistics

    Bertrand Drouvot <bertranddrouvot.pg@gmail.com> — 2024-12-12T05:07:23Z

    Hi,

On Thu, Dec 12, 2024 at 09:20:15AM +0900, Michael Paquier wrote:
> On Wed, Dec 11, 2024 at 07:32:38AM +0000, Bertrand Drouvot wrote:
> > On Wed, Dec 11, 2024 at 02:56:08PM +0900, Michael Paquier wrote:
> >> Your suggestion does not look completely right to me.  There is
> >> nothing preventing us from using something else than event counters
> >> since we don't use memcpy() and there is no comparison work, no?  It
> >> seems to me that we could remove the entire sentence instead.
> > 
> > Do you mean also remove the comments in pgstat_function_flush_cb() and
> > pgstat_subscription_flush_cb()? Those comments look fine to me given
> > the places where those pending entries are created meaning in
> > pgstat_init_function_usage() for the functions and pgstat_report_subscription_error()
> > and pgstat_report_subscription_conflict() for the subscriptions.
> 
> My apologies for the confusion.  I see no problem with the existing
> comments in pgstat_subscription_flush_cb() and
> pgstat_function_flush_cb() because they still apply.

got it, thanks for the clarification.

> The only thing we should do here is to remove the comment for
> PgStat_FunctionCounts because we could add pointers or something else
> than plain counters in this structure, 

I see what you mean and you are right (I misread the initial comment so updated
it wrongly). Removed in v2 attached.

> and fix the comment of
> PgStat_TableCounts in the lines of what you are suggesting.

Yeap. I also just realized that the same kind of comments are missing for
PgStat_BgWriterStats and PgStat_CheckpointerStats (for which we make use
of pg_memory_is_all_zeros() to detect whether there are any stats updates to
apply). Adding those in passing.

Regards,

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

  6. Re: Fix comments related to pending statistics

    Michael Paquier <michael@paquier.xyz> — 2024-12-12T08:00:34Z

    On Thu, Dec 12, 2024 at 05:07:23AM +0000, Bertrand Drouvot wrote:
> Yeap. I also just realized that the same kind of comments are missing for
> PgStat_BgWriterStats and PgStat_CheckpointerStats (for which we make use
> of pg_memory_is_all_zeros() to detect whether there are any stats updates to
> apply). Adding those in passing.

Good point.  I've slightly tweaked a few things for consistency and
the result looked OK, so applied.
--
Michael