Re: pgstat: Flush some statistics within running transactions, take 2

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Sami Imseih <samimseih(dot)pg(at)gmail(dot)com>
Cc: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, Lukas Fittl <lukas(at)fittl(dot)com>
Subject: Re: pgstat: Flush some statistics within running transactions, take 2
Date: 2026-09-04 07:58:29
Message-ID: app6JRYGTfHEKA99@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Sep 03, 2026 at 07:04:00AM -0500, Sami Imseih wrote:
> Thanks! I also found a few other cases with missing DROP that we might
> as well as fix now. done in v12.

I have begun processing the refactoring of 0001, where the counters
are split into two sub-structures, and there was one thing that stood
out: the test is useful on its own. In pgstat_relation_flush_cb(), I
have removed the reset of the live/dead counters, then ran the
main regression test suite to note that nothing fails, except this
test. The code path is taken, but nothing is exposed in the view to
show a diff.

In short, extracted this part and applied it after some edits. The
DROP of table trunc_stats_test5 should have been in 0001, not 0002.

I am not sure about the extra DROP queries for the other tables:
sometimes we keep around a few objects for the sake of pg_upgrade, so
I would recommend to just leave that be.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ayush Tiwari 2026-09-04 08:01:03 [PATCH] Fix WAL block image length diagnostic
Previous Message Richard Guo 2026-09-04 07:49:12 Re: Assert failure in try_nestloop_path()