From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com> |
Cc: | Alexander Lakhin <exclusion(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Recent pg_rewind test failures in buildfarm |
Date: | 2025-04-21 01:17:40 |
Message-ID: | aAWctHTY_Dml_5a0@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 | Content-Type | Size |
---|---|---|
0001-Remove-assertion-in-pgstat.c.patch | text/x-diff | 714 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2025-04-21 01:52:53 | Re: Typos in the code and README |
Previous Message | Michael Paquier | 2025-04-20 23:21:12 | Re: Typos in the code and README |