On Sat, Sep 06, 2025 at 10:01:24AM +0900, Michael Paquier wrote: > A last thing that I was not able to spend much time on is how much it > is possible to mess up with the shared memory state. If it is worse > than I suspected initially, where an OOM in a first session can cause > crashes because of incorrect dshash entries in shmem depending on the > stats kind fetched, a backpatch will be required, indeed. The change > is not really invasive, so that's OK on this side.
OK, I have played a bit more with all that, corrupting the shared hashtable of pgstats. At the end, I have used a version close to what I have sent previously that changes pgstat_init_entry() to return NULL on OOM with dsa_allocate_extended(), as any other possible errors that could happen in this call involve elog(ERROR) and not-reachable cases. pgstat_read_statsfile() has been changed to raise an ERROR instead, which is what we did previously, giving priority to the on-disk stats when the environment is under memory pressure at startup. The patch has required a few tweaks in the back-branches, nothing huge. Thanks for the report! -- Michael
signature.asc
Description: PGP signature
