> On Thu, Apr 17, 2025 at 07:05:36PM GMT, Ni Ku wrote: > I also have a related question about how ftruncate() is used in the patch. > In my testing I also see that when using ftruncate to shrink a shared > segment, the memory is freed immediately after the call, even if other > processes still have that memory mapped, and they will hit SIGBUS if they > try to access that memory again as the manpage says. > > So am I correct to think that, to support the bufferpool shrinking case, it > would not be safe to call ftruncate in AnonymousShmemResize as-is, since at > that point other processes may still be using pages that belong to the > truncated memory? > It appears that for shrinking we should only call ftruncate when we're sure > no process will access those pages again (eg, all processes have handled > the resize interrupt signal barrier). I suppose this can be done by the > resize coordinator after synchronizing with all the other processes. > But in that case it seems we cannot use the postmaster as the coordinator > then? b/c I see some code comments saying the postmaster does not have > waiting infrastructure... (maybe even if the postmaster has waiting infra > we don't want to use it anyway since it can be blocked for a long time and > won't be able to serve other requests).
There is already a coordination infrastructure, implemented in the patch 0006, which will take care of this and prevent access to the shared memory until everything is resized.
