On Wed, Feb 26, 2025 at 9:50 AM Srinath Reddy <srinath2...@gmail.com> wrote:
> > > On Wed, Feb 26, 2025 at 9:23 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > >> Srinath Reddy <srinath2...@gmail.com> writes: >> > when we kill postmaster using kill -9 and start immediately it crashes >> with >> >> FATAL: pre-existing shared memory block (key 2495405, ID 360501) is >> still >> >> in use >> >> "Doctor, it hurts when I do this!" >> >> "So don't do that!" >> >> This is not a supported way of shutting down the postmaster, and it >> never will be. Use SIGINT, or SIGQUIT if you are in a desperate >> hurry and are willing to have the next startup take longer. >> > i was actually trying to recreate power outage scenario using > node->kill9(),node->start() in a custom tap test,then i found this crash. > > >> >> I think the specific reason you are seeing this is that it takes >> nonzero time for the postmaster's orphaned child processes to >> notice that the postmaster is gone and terminate. As long as >> any of those children remain, the shared memory block will have >> a nonzero reference count. The new postmaster sees that and >> refuses to start, for the very sound reason that it risks >> data corruption if it brings up a new set of worker processes >> while any of the old ones are still running. >> >> regards, tom lane >> > > i am guessing you mean "reference count to shared memory block" means > shmem_nattach right? i think this will be incremented by 1 when a process > attached to the shmem segment using shmat() in postgres case its the > postmaster who attaches during creation of shmem segment and detaches > during postmaster's on_shmem_exit is called during if it exits properly or > not dies suddenly (as the case with kill -9) ,during detaching only the > shmem_nattach will be decremented by 1 ,AFAIK the child processes will get > to use the shmem segment but never attaches or detaches so they are not > effecting the shmem_nattach.so as the shmem_nattach is not > 0 PGSharedMemoryAttach thinks the shmem state is still attached and in use. > > >
