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.
regards, tom lane
