postgres.git / summary / log / commit / refs

commit    e9ab8677bfc581bdfbcc1e5d286d7d6269741b90
Author:   Michael Paquier <michael@paquier.xyz>
Date:     Wed Apr 23 04:54:56 2025 +0000
First released in: 18.0, 15.13, 16.9, 17.5

    Remove assertion based on pending_since in pgstat_report_stat()
    
    This assertion, based on pending_since (timestamp used to prevent stats
    reports to be too frequent or should a partial flush happen), is reached
    when it is found that no data can be flushed but a previous call of
    pgstat_report_stat() determined that some stats data has been found as
    in need of a flush.  So pending_since is set when some stats data is
    pending (in non-force mode) or if report attempts are too frequent, and
    reset to 0 once all stats have been flushed.
    
    Since 5cbbe70a9cc6, WAL senders have begun to report their stats on a
    periodic basis for IO stats in v16~ and backend stats on HEAD, creating
    some friction with the concurrent pgstat_report_stat() calls that can
    happen in the context of a WAL sender (shutdown callback doing a final
    report or backend-related code paths).  This problem is the cause of
    spurious failures in the TAP tests.
    
    In theory, this assertion can be also reached in v15, even if that's
    very unlikely.  For example, a process, say a background worker, could
    do periodic and direct stats flushes with concurrent calls of
    pgstat_report_stat() that could cause conflicting values of
    pending_since.  This can be done with WAL or SLRU stats flushes using
    pgstat_flush_wal() or pgstat_slru_flush().  HEAD makes this situation
    easier to happen with custom cumulative stats.
    
    This commit removes the assertion altogether, per discussion, as it is
    more useful to keep the state of things as they are for the WAL sender.
    The assertion could use a special state based on for example
    am_walsender, but I doubt that this would be meaningful in the long run
    based on the other arguments raised while discussing this issue.
    
    Reported-by: Tom Lane <tgl@sss.pgh.pa.us>
    Reported-by: Andres Freund <andres@anarazel.de>
    Discussion: https://postgr.es/m/1489124.1744685908@sss.pgh.pa.us
    Discussion: https://postgr.es/m/dwrkeszz6czvtkxzr5mqlciy652zau5qqnm3cp5f3p2po74ppk@omg4g3cc6dgq
    Backpatch-through: 15


 src/backend/utils/activity/pgstat.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/backend/utils/activity/pgstat.c b/src/backend/utils/activity/pgstat.c
index 26da09d73ab..cb17dc0c4bd 100644
--- a/src/backend/utils/activity/pgstat.c
+++ b/src/backend/utils/activity/pgstat.c
@@ -603,7 +603,6 @@ pgstat_report_stat(bool force)
 		!have_slrustats &&
 		!pgstat_have_pending_wal())
 	{
-		Assert(pending_since == 0);
 		return 0;
 	}
 


[parent: d2b065084a4a]