Re: BF mamba failure
Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
From: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Kouber Saparev <kouber@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2024-11-14T10:07:41Z
Lists: pgsql-hackers
Hi, On Thu, Nov 14, 2024 at 04:55:23PM +0900, Michael Paquier wrote: > I've been going through this patch again, and the failures that could > be seen because of such failures, like standbys failing in an > unpredictible way is not cool, so I am planning to apply the attached > down to 15 now that the release has colled down. At the end I am not > really stressing about this addition in the structure for the sake of > making the stats entries safe to handle. I don't think the addition is a concern too. > I did not like much the name "agecount" though, used to cross-check > how many times an entry is reused in shared memory and in the local > copy we keep in a process, so I've renamed it to "generation". "generation" sounds more appropriate to me too. The approach to avoid the error sounds reasonable to me. Just 2 comments about the patch: === 1 Maybe use "generation" instead of generation in the comments (where it's not done, some comments do it already). === 2 We could think about adding a test. That should be doable with replication slots or custom pgstats kinds and probably injection points. But I'm not sure that's worth it, as the code in the patch looks "simple" enough. Thoughts? Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
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