mephysto <mephystoonhell@gmail.com> writes: > I have some problems in a postgres cluster when I try to execute a backup. > ... > FATAL: semctl(983046, 3, SETVAL, 0) failed: Invalid argument > ... > LOG: could not remove shared memory segment "/PostgreSQL.1804289383": No > such file or directory > LOG: semctl(786432, 0, IPC_RMID, ...) failed: Invalid argument > LOG: semctl(819201, 0, IPC_RMID, ...) failed: Invalid argument > LOG: semctl(851970, 0, IPC_RMID, ...) failed: Invalid argument > LOG: semctl(884739, 0, IPC_RMID, ...) failed: Invalid argument > LOG: semctl(917508, 0, IPC_RMID, ...) failed: Invalid argument > LOG: semctl(950277, 0, IPC_RMID, ...) failed: Invalid argument > LOG: semctl(983046, 0, IPC_RMID, ...) failed: Invalid argument > LOG: semctl(1015815, 0, IPC_RMID, ...) failed: Invalid argument
Assuming you didn't manually destroy the shared memory segment and semaphores, the only very likely explanation for this is that another postmaster instance started up, used the same memory and semaphore IDs, and then removed them when it shut down. This should be impossible given the interlocks around shared memory segment creation and use of a data directory; but it's possible to break those interlocks if you try hard enough.
I speculate that you've got a postmaster-startup script that unconditionally removes the postmaster.pid lock file before starting the postmaster, and that your backup procedure or some other routine action is invoking that even when there might be a live postmaster already.
If so, the answer is simple: get rid of the script's attempt to remove the lock file. And have a word with whoever put it in. *Nothing* except the postmaster's own code should *ever* remove postmaster.pid.