Hi Tom, I am using only pg_ctl to start and stop my database. At the moment I do not use any script.
Bye. Meph On 17 July 2015 at 16:32, Tom Lane <t...@sss.pgh.pa.us> wrote: > mephysto <mephystoonh...@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 >
