On Sun, Nov 26, 2023 at 10:34:59PM -0500, Tom Lane wrote:
> I'm good with that answer --- I doubt that this test sequence is
> proving anything that's worth the cycles it takes. If it'd catch
> oversights like failing to add new stats types to the "reset all"
> code path, then I'd be for keeping
On Mon, Nov 27, 2023 at 02:01:51PM -0500, Tom Lane wrote:
> The problem as I see it is that this test:
>
> SELECT :io_stats_post_reset < :io_stats_pre_reset;
>
> requires an assumption that less I/O has happened since the commanded
> reset action than happened before it (extending back to the
Andres Freund writes:
> I am probably under-caffeinated: What precisely is the potential race? Just
> that the timestamps on some system might not be granular enough?
The problem as I see it is that this test:
SELECT :io_stats_post_reset < :io_stats_pre_reset;
requires an assumption that less
Hi,
On 2023-11-27 11:56:19 +0900, Michael Paquier wrote:
> I was ready to argue that we'd better keep this test and keep it close
> to the end of stats.sql while documenting why things are kept in this
> order, but two resets done on the same shared stats type would still
> be prone to race
Hi,
On 2023-11-27 15:49:01 +0530, Bharath Rupireddy wrote:
> On Mon, Nov 27, 2023 at 8:26 AM Michael Paquier wrote:
> > but two resets done on the same shared stats type would still
> > be prone to race conditions without all the previous activity done in
> > the tests (like pg_stat_wal).
>
>
On Mon, Nov 27, 2023 at 8:26 AM Michael Paquier wrote:
>
> I was ready to argue that we'd better keep this test and keep it close
> to the end of stats.sql while documenting why things are kept in this
> order,
It's easy for someone to come and add pg_stat_reset_shared() before
the end without
Michael Paquier writes:
> With all that in mind and because we have checks for the individual
> targets with pg_stat_reset_shared(), I would agree to just remove it
> entirely. Say as of the attached?
I'm good with that answer --- I doubt that this test sequence is
proving anything that's worth
On Sat, Nov 25, 2023 at 02:34:40PM -0500, Tom Lane wrote:
> -- Test that reset_shared with no argument resets all the stats types
> -- supported (providing NULL as argument has the same effect).
> SELECT pg_stat_reset_shared();
Right, this has switched pg_stat_reset_shared() from doing nothing to
I wrote:
> I'm a bit mystified by this. This test was introduced in Andres'
> commit 10a082bf7 of 2023-02-11, and it seems to have been stable
> since then. I trawled the buildfarm logs going back three months
> and found no similar failures. So why's it failing now? The
> most plausible
In the past few days we've had two buildfarm failures[1][2] in the
stats regression test that look like
@@ -1582,7 +1582,7 @@
SELECT :io_stats_post_reset < :io_stats_pre_reset;
?column?
--
- t
+ f
(1 row)
-- test BRIN index doesn't block HOT update
I'm a bit mystified by this.
10 matches
Mail list logo
