Re: [Proposal] Adding callback support for custom statistics kinds

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Sami Imseih <samimseih(at)gmail(dot)com>
Cc: Peter Eisentraut <peter(at)eisentraut(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [Proposal] Adding callback support for custom statistics kinds
Date: 2026-07-15 01:53:53
Message-ID: alboMa8cH3CMHwwi@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jul 14, 2026 at 11:31:33AM -0500, Sami Imseih wrote:
> .. and you just made me realize that there is an existing bug in
> cleanup.

Bug that becomes real once 0002 is on the stack, especially with the
two error conditions I've mentioned upthread as we would still discard
the files in the WRITE case as we would likely have an ferror()
encounter.

> In the pgstat_write path, STATS_WRITE is passed unconditionally to finish()
> regardless of the outcome of the write to the core temp stats file, and in the
> pgstat_read path, the finish() is completely skipped in the case the
> core permanent
> stats file is missing. So, in both cases we need to track if the respective core
> files are in a proper state and if not pass STATS_DISCARD to finish().
>
> See the attached:
>
> 0001 - reverts ed823da12891

Fixed this confusion as 381b3cfe2be0, based on Peter's feedback.

> 0002 - Ensures that the callbacks receive the correct STATS_DISCARD when
> there is core file failures so the extensions can perform the proper cleanup.
> This is the existing cleanup handling bug.
>
> 0003 - Changes to_serialized_data to return a bool. It handles this case
> by removing the temp core stats file, but unlike v1 it does not need to
> do so by jumping to a new "error" block.

Even after writing the sentence in the first paragraph, the symmetry
has value once 0003 is added, so I have merged 0002 and 0003 together,
and applied the result after a few minor tweaks. Thanks.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Chao Li 2026-07-15 02:45:23 Re: pgbench --continue-on-error: clarify TPS and failure reporting
Previous Message Hayato Kuroda (Fujitsu) 2026-07-15 01:31:43 RE: sequencesync worker race with REFRESH SEQUENCES