Le mar. 30 nov. 2021 à 00:25, Tom Lane <t...@sss.pgh.pa.us> a écrit :
> Guillaume Lelarge <guilla...@lelarge.info> writes: > > Le lun. 29 nov. 2021 à 22:27, Tom Lane <t...@sss.pgh.pa.us> a écrit : > >> I'm checking it in HEAD though; perhaps there's something else wrong > >> in the back branches? > > > That's also what I was thinking. I was only trying with v14. I just > checked > > with v15devel, and your patch works alright. So there must be something > > else with back branches. > > AFAICT the patch fixes what it intends to fix in v14 too. The reason the > residual leak is worse in v14 is that the sinval message queue is bulkier. > We improved that in HEAD in commit 3aafc030a. I wanted to make sure that commit 3aafc030a fixed this issue. So I did a few tests: without 3aafc030a, without your latest patch 1182148 kB max resident size with 3aafc030a, without your latest patch 1306812 kB max resident size without 3aafc030a, with your latest patch 1182128 kB max resident size with 3aafc030a, with your latest patch 180996 kB max resident size Definitely, 3aafc030a and your latest patch allow PostgreSQL to use much less memory. Going from 1GB to 180MB is awesome. I tried to cherry-pick 3aafc030a on v14, but it didn't apply cleanly, and the work was a bit overwhelming for me, at least in the morning. I'll try again today, but I don't have much hope. I'm not sure if I want to > take the risk of back-patching that, even now that it's aged a couple > months in the tree. It is a pretty localized fix, but it makes some > assumptions about usage patterns that might not hold up. > > I understand. Of course, it would be better if it could be fixed for each supported version but I'm already happy that it could be fixed in the next release. -- Guillaume.