| От | Michael Paquier |
|---|---|
| Тема | Re: Recent pg_rewind test failures in buildfarm |
| Дата | |
| Msg-id | aAWctHTY_Dml_5a0@paquier.xyz обсуждение |
| Ответ на | Re: Recent pg_rewind test failures in buildfarm (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>) |
| Ответы |
Re: Recent pg_rewind test failures in buildfarm
|
| Список | 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
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера