Re: BF mamba failure
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Kouber Saparev <kouber@gmail.com>
Cc: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2025-09-12T00:37:30Z
Lists: pgsql-hackers
On Thu, Sep 11, 2025 at 04:35:01PM +0300, Kouber Saparev wrote: > 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. The shutdown is caused by the startup process choking on redo. FWIW > Thanks for the feedback, and let me know if I could provide any additional > info. Okay, the bit about the cascading standby is a useful piece of information. Do you have some data about the relation reported in the error message this is choking on based on its OID? Is this actively used in read-only workloads, with the relation looked at in the cascading standby? Is hot_standby_feedback enabled in the cascading standby? With which process has this cascading standby been created? Does the workload of the primary involve a high consumption of OIDs for relations, say many temporary tables? Another thing that may help is the WAL record history. Are you for example seeing attempts to drop twice the same pgstats entry in WAL records? Perhaps the origin of the problem is in this area. A refcount of 2 is relevant, of course. I have looked a bit around but nothing has popped up here, so as far as I know you seem to be the only one impacted by that. 1d6a03ea4146 and dc5f9054186a are in 17.3, so perhaps something is still off with the drop when applied to cascading standbys. A vital piece of information may also be with "generation", which would show up in the error report thanks to bdda6ba30cbe, and that's included in 17.6. A first thing would be to update to 17.6 and see how things go for these cascading setups. If it takes a couple of weeks to have one report, we have a hunt that may take a few months at least, except if somebody is able to find out the race condition here, me or someone else. -- Michael
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