Re: Recent pg_rewind test failures in buildfarm - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Recent pg_rewind test failures in buildfarm
Date
Msg-id aAWctHTY_Dml_5a0@paquier.xyz
Whole thread Raw
In response to Re: Recent pg_rewind test failures in buildfarm  (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>)
List pgsql-hackers
On Tue, Apr 15, 2025 at 05:50:32AM +0000, Bertrand Drouvot wrote:
> Sorry, can't look at the details right now but it might be linked to
> 039549d70f6 which is recent enough and in this area. Will give it a look once
> I've time.

Playing catch-up with various things this week, and I have been
looking at this one.

So, we are triggering this assertion in the shutdown sequence of the
WAL sender because there is nothing to flush based on what the
callbacks are reporting, still pending_since could have been set by a
previous call of pgstat_report_stat(), which could come from a
PostgresMain() path for example, depending on the frequency of such
calls.  The important point is that we don't lose WAL sender stats at
shutdown, and well, we don't lose any data for the WAL sender based on
what this assertion tells us, just that there is some friction with
the new I/O and backend flush calls.

pg_stat_io has been added in v16, but isn't that something that could
be reached even today down to v15?  For example, imagine the case of a
background worker that does periodic stats reports with interactions
on existing stats.  pgstats stored in shmem has been added in v15.

Thoughts?
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Typos in the code and README
Next
From: David Rowley
Date:
Subject: Re: Typos in the code and README