Re: Backup fatal issue

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 <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> mephysto <mephystoonhell(at)gmail(dot)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
>