On Thu, Nov 28, 2024 at 11:30 AM Dmitry Dolgov <9erthali...@gmail.com> wrote: > on Linux, this fact is already used in the patch. The idea that we could put > upper boundary on the size of other mappings based on total available memory > comes from the fact that anonymous mappings, that are much larger than memory, > will fail without overcommit. With overcommit it becomes different, but if > allocations are hitting that limit I can imagine there are bigger problems > than > shared buffer resize. > > This approach follows the same ideas already used in the patch, and have the > same trade offs: no address changes, but questions about portability.
I definitely welcome the fact that you have some platform-specific knowledge of the Linux behavior, because that's expertise that is obviously quite useful here and which I lack. I'm personally not overly concerned about whether it works on every other platform -- I would prefer an implementation that works everywhere, but I'd rather have one that works on Linux than have nothing. It's unclear to me why operating systems don't offer better primitives for this sort of thing -- in theory there could be a system call that sets aside a pool of address space and then other system calls that let you allocate shared/unshared memory within that space or even at specific addresses, but actually such things don't exist. All that having been said, what does concern me a bit is our ability to predict what Linux will do well enough to keep what we're doing safe; and also whether the Linux behavior might abruptly change in the future. Users would be sad if we released this feature and then a future kernel upgrade causes PostgreSQL to completely stop working. I don't know how the Linux kernel developers actually feel about this sort of thing, but if I imagine myself as a kernel developer, I can totally see myself saying "well, we never promised that this would work in any particular way, so we're free to change it whenever we like." We've certainly used that argument here countless times. -- Robert Haas EDB: http://www.enterprisedb.com
