> On Fri, Apr 18, 2025 at 10:06:23AM GMT, Konstantin Knizhnik wrote: > The only drawback is that we are loosing content of shared buffers in case > of resize. It may be sadly, but not looks like there is no better > alternative.
No, why would we loose the content? If we do mremap, it will leave the content as it is. If we do munmap/mmap with an anonymous backing file, it will also keep the content in memory. The same with another proposal about using ftruncate/fallocate only, both will leave the content untouch unless told to do otherwise. > But there are still some dependencies on shared buffers size which are not > addressed in this PR. > I am not sure how critical they are and is it possible to do something here, > but at least I want to enumerate them: Righ, I'm aware about those (except the AIO one, which was added after the first version of the patch), and didn't address them yet due to the same reason you've mentioned -- they're not hard errors, rather inefficiencies. But thanks for the reminder, I keep those in the back of my mind, and when the rest of the design will be settled down, I'll try to address them as well.
