Re: BF mamba failure
Kouber Saparev <kouber@gmail.com>
From: Kouber Saparev <kouber@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>,
pgsql-hackers@lists.postgresql.org
Date: 2025-09-11T13:35:01Z
Lists: pgsql-hackers
На чт, 11.09.2025 г. в 2:28 Michael Paquier <michael@paquier.xyz> написа: > As a start, are these failures only in the startup process? Has the > startup process reached a consistent state when the problem happens > because the replay code is too eager at removing the stats entries? > Has it not reached a consistent state. These could be useful hints to > extract a reproducible test case, looking for common patterns. > The pattern is the same, although I am not 100% sure that the same replica is having this - it is a cascaded streaming replica, i.e. a replica of another replica. Once we had this in October 2024, with version 15.4, then in August 2025 with 17.3, and now in September again (17.3). The database is working for month(s) perfectly fine in a heavy production workload (lots of WALs etc.), and then all of a sudden it shuts down. Thanks for the feedback, and let me know if I could provide any additional info. -- Kouber
Commits
-
Add information about "generation" when dropping twice pgstats entry
- 769be67a3c7a 15.14 landed
- f770006928d0 16.10 landed
- bdda6ba30cbe 17.6 landed
- ab74ce4dc909 18.0 landed
- 84b32fd22830 19 (unreleased) landed
-
Fix race conditions with drop of reused pgstats entries
- 154c5b42a3d8 15.10 landed
- afa20845dd13 16.6 landed
- 1d6a03ea4146 17.2 landed
- 818119afccd3 18.0 landed