On Sun, Nov 01, 2026 at 10:37:16PM -0500, shihao zhong wrote: > Thanks for looking into this.
At the end I have no objection to setting up the checkpoint start flag to close this race, so applied down to v14. I have reworded quite a bit the comments, though, to mention a little bit more the similarities with the COMMIT PREPARED path and somewhat the regular COMMIT path, as these relate as well to the pg_xact updates. The difference here is that the file is on disk. > One is multixact creation [1]. > > The other two are CLOG truncation and hash index bucket allocation [2]. I am not sure of I will be able to look at any of them, but perhaps others will be able to chime in. Another thing that is worth mentioning here is that we have more problems around 2PC and recovery setups. See the reason behind a6c70f68cdeb and its thread: https://postgr.es/m/[email protected] There is a deeper design issue in this area of the code where we have the idea to look at the CLOGs for the commit or aborted states of the 2PC transactions without having reached a consistent state (both crash and base backup recovery included). In this case the CLOG data may be inconsistent. It's different than what you have reported here: it's not OK to have a checkpoint discard data we are going to need to decide if a 2PC transaction has been aborted or not. While the test is useful to reproduce the issue, I was not sure that it is mandatory to run it for such a short race window, so I have left it out of the equation. If anybody has else has an opinion to offer about that, feel free. -- Michael
signature.asc
Description: PGP signature
