| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Sami Imseih <samimseih(dot)pg(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: pgstat: allow a stats kind to use its own dedicated dsa/dshash |
| Date: | 2026-10-18 06:00:47 |
| Message-ID: | atRgjrilxWTF4lYU@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Oct 17, 2026 at 09:46:01PM -0500, Sami Imseih wrote:
> We need to force a flush when test_custom_stats_var_update(), which calls
> pgstat_prep_pending_entry(), is followed by test_custom_stats_var_report()
> from another backend. This is only the case for the batched updates.
@@ -86,7 +86,8 @@ foreach my $stats_kind (@var_stats_kinds)
q(select test_custom_stats_var_update(name)
from (values ('entry1', 2), ('entry2', 3),
('entry3', 2), ('entry4', 3)) as stats(name, n),
- generate_series(1, n)));
+ generate_series(1, n);
+ select pg_stat_force_next_flush()));
Yes, an extra pg_stat_force_next_flush() should be enough to make the
tests stable. Will apply. Thanks for the patch.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexander Lakhin | 2026-10-18 07:00:00 | Re: pgstat: allow a stats kind to use its own dedicated dsa/dshash |
| Previous Message | Shubhankar Anand Kulkarni | 2026-10-18 05:00:15 | Re: PG19: flat-copied RelOptInfos share extension_state with the original rel |