On Mon, Jan 08, 2024 at 11:16:27AM -0600, Nathan Bossart wrote: > On Mon, Jan 08, 2024 at 10:53:17AM +0530, Bharath Rupireddy wrote: >> 1. I think we need to add some notes about this new way of getting >> shared memory for external modules in the <title>Shared Memory and >> LWLocks</title> section in xfunc.sgml? This will at least tell there's >> another way for external modules to get shared memory, not just with >> the shmem_request_hook and shmem_startup_hook. What do you think? > > Good call. I definitely think this stuff ought to be documented. After a > quick read, I also wonder if it'd be worth spending some time refining that > section.
+1. It would be a second thing to point at autoprewarm.c in the docs as an extra pointer that can be fed to users reading the docs. >> 3. IIUC, this feature eventually makes both shmem_request_hook and >> shmem_startup_hook pointless, no? Or put another way, what's the >> significance of shmem request and startup hooks in lieu of this new >> feature? I think it's quite possible to get rid of the shmem request >> and startup hooks (of course, not now but at some point in future to >> not break the external modules), because all the external modules can >> allocate and initialize the same shared memory via >> dsm_registry_init_or_attach and its init_callback. All the external >> modules will then need to call dsm_registry_init_or_attach in their >> _PG_init callbacks and/or in their bg worker's main functions in case >> the modules intend to start up bg workers. Am I right? > > Well, modules might need to do a number of other things (e.g., adding > hooks) that can presently only be done when preloaded, in which case I > doubt there's much benefit from switching to the DSM registry. I don't > really intend for it to replace the existing request/startup hooks, but > you're probably right that most, if not all, could use the registry > instead. IMHO this is well beyond the scope of this thread, though. Even if that's not in the scope of this thread, just removing these hooks would break a lot of out-of-core things, and they still have a lot of value when extensions expect to always be loaded with shared. They don't cost in maintenance at this stage. -- Michael
signature.asc
Description: PGP signature
