On Thu, Jun 8, 2023 at 8:44 AM Hannu Krosing <han...@google.com> wrote: > > That sounds like a bad idea, dynamic shared memory is more expensive > > to maintain than our static shared memory systems, not in the least > > because DSM is not guaranteed to share the same addresses in each > > process' address space. > > Then this too needs to be fixed
Honestly, I'm struggling to respond to this non-sarcastically. I mean, I was the one who implemented DSM. Do you think it works the way that it works because I considered doing something smart and decided to do something dumb instead? Suppose you have two PostgreSQL backends A and B. If we're not running on Windows, each of these was forked from the postmaster, so things like the text and data segments and the main shared memory segment are going to be mapped at the same address in both processes, because they inherit those mappings from the postmaster. However, additional things can get mapped into the address space of either process later. This can happen in a variety of ways. For instance, a shared library can get loaded into one process and not the other. Or it can get loaded into both processes but at different addresses - keep in mind that it's the OS, not PostgreSQL, that decides what address to use when loading a shared library. Or, if one process allocates a bunch of memory, then new address space will have to be mapped into that process to handle those memory allocations and, again, it is the OS that decides where to put those mappings. So over time the memory mappings of these two processes can diverge arbitrarily. That means that if the same DSM has to be mapped into both processes, there is no guarantee that it can be placed at the same address in both processes. The address that gets used in one process might not be available in the other process. It's worth pointing out here that there are no portable primitives available for a process to examine what memory segments are mapped into its address space. I think it's probably possible on every OS, but it works differently on different ones. Linux exposes such details through /proc, for example, but macOS doesn't have /proc. So if we're using standard, portable primitives, we can't even TRY to put the DSM at the same address in every process that maps it. But even if we used non-portable primitives to examine what's mapped into the address space of every process, it wouldn't solve the problem. Suppose 4 processes want to share a DSM, so they all run around and use non-portable OS-specific interfaces to figure out where there's a free chunk of address space large enough to accommodate that DSM and they all map it there. Hooray! But then say a fifth process comes along and it ALSO wants to map that DSM, but in that fifth process the address space that was available in the other four processes has already been used by something else. Well, now we're screwed. The fact that DSM is expensive and awkward to use isn't a defect in the implementation of DSM. It's a consequence of the fact that the address space mappings in one PostgreSQL backend can be almost arbitrarily different from the address space mappings in another PostgreSQL backend. If only there were some kind of OS feature available that would allow us to set things up so that all of the PostgreSQL backends shared the same address space mappings! Oh, right, there is: THREADS. The fact that we don't use threads is the reason why DSM sucks and has to suck. In fact it's the reason why DSM has to exist at all. Saying "fix DSM instead of using threads" is roughly in the same category as saying "if the peasants are revolting because they have no bread, then let them eat cake." Both statements evince a complete failure to understand the actual source of the problem. With apologies for my grumpiness, -- Robert Haas EDB: http://www.enterprisedb.com
