> On Wed, Nov 27, 2024 at 10:20:27AM GMT, Robert Haas wrote: > > > > > > code, but I'm not sure exactly which points are safe. If we have no > > > code anywhere that assumes the address of an unpinned buffer can't > > > change before we pin it, then I guess the check for pins is the only > > > thing we need, but I don't know that to be the case. > > > > Probably I'm missing something here. What scenario do you have in mind, > > when the address of a buffer is changing? > > I was assuming that if you expand the mapping for shared_buffers, you > can't count on the new mapping being at the same address as the old > mapping. If you can, that makes things simpler, but what if the OS has > mapped something else just afterward, in the address space that you're > hoping to use when you expand the mapping?
Yes, that's the whole point of the exercise with remap -- to keep addresses unchanged, making buffer management simpler and allowing resize mappings quicker. The trade off is that we would need to take care of shared mapping placing. My understanding is that clashing of mappings (either at creation time or when resizing) could happen only withing the process address space, and the assumption is that by the time we prepare the mapping layout all the rest of mappings for the process are already done. But I agree, it's an interesting question -- I'm going to investigate if those assumptions could be wrong under certain conditions. Currently if something else is mapped at the same address where we want to expand the mapping, we will get an error and can decide how to proceed (e.g. if it happens at creation time, proceed with a single mapping, otherwise ignore mapping resize).
