Re: Backup fatal issue

​Hi Melvin,
I tried to execute pg_dump and after I tried to launch pg_start_backup and
pg_stop_backup. In both cases, I did not receive any error, so I decided to
investigate in BarMan.

Thanks for your help.

Bye.

Meph​

On 17 July 2015 at 16:16, Melvin Davidson <melvin6925(at)gmail(dot)com> wrote:

> If this is occurring with Barman, try doing a manual backup.
> IE: pg_dump your_database > /tmp/somefile.sql
>
> If that works, then the problem is with Barman or it's configuration.
>
> On Fri, Jul 17, 2015 at 10:07 AM, Mephysto <mephystoonhell(at)gmail(dot)com>
> wrote:
>
>> Hi Melvin,
>> I am using Pstgres 9.4.4 in a virtualized Debian Linux 8.0. I do not know
>> backup command because is launched by BARMAN 1.4.1. I have tried many times
>> to execute the backup. I have restarted and reinstalled Postgres and I also
>> rebooted OS many times.
>>
>> Thanks for your help.
>>
>> Meph
>>
>> On 17 July 2015 at 15:12, Melvin Davidson <melvin6925(at)gmail(dot)com> wrote:
>>
>>> I think we need just a little bit more information.
>>>
>>> What is the O/S?
>>> What is the PostgreSQL version?
>>> What is the backup command?
>>> Does this always occur with the same command?
>>> Did you need to restarrt PostgreSQL after this started?
>>>
>>>
>>>
>>> On Fri, Jul 17, 2015 at 3:29 AM, mephysto <mephystoonhell(at)gmail(dot)com>
>>> wrote:
>>>
>>>> Hi there,
>>>> I have some problems in a postgres cluster when I try to execute a
>>>> backup.
>>>> This is the log of entire operation:
>>>>
>>>> LOG: connection received: host=91.121.182.110 port=54957
>>>> LOG: connection authorized: user=postgres database=postgres
>>>> LOG: statement: BEGIN
>>>> LOG: statement: SET application_name TO barman
>>>> LOG: statement: SHOW "data_directory"
>>>> LOG: connection received: host=91.121.182.110 port=54958
>>>> LOG: connection authorized: user=postgres database=postgres
>>>> LOG: statement: BEGIN
>>>> LOG: statement: SET application_name TO barman
>>>> LOG: statement: SELECT name, setting FROM pg_settings WHERE name IN
>>>> ('config_file', 'hba_file', 'ident_file')
>>>> LOG: connection received: host=91.121.182.110 port=54959
>>>> LOG: connection authorized: user=postgres database=postgres
>>>> LOG: statement: BEGIN
>>>> LOG: statement: SET application_name TO barman
>>>> LOG: statement: SELECT spcname, oid, pg_tablespace_location(oid) AS
>>>> spclocation FROM pg_tablespace WHERE pg_tablespace_location(oid) != ''
>>>> LOG: connection received: host=91.121.182.110 port=54960
>>>> LOG: connection authorized: user=postgres database=postgres
>>>> LOG: statement: BEGIN
>>>> LOG: statement: SET application_name TO barman
>>>> LOG: statement: select pg_is_in_recovery()
>>>> LOG: statement: SELECT xlog_loc, (pg_xlogfile_name_offset(xlog_loc)).*,
>>>> now() FROM pg_start_backup('Barman backup redevodb_citrix
>>>> 20150717T091702',false) as xlog_loc
>>>> LOG: connection received: host=91.121.182.110 port=54988
>>>> FATAL: semctl(983046, 3, SETVAL, 0) failed: Invalid argument
>>>> LOG: server process (PID 1756) exited with exit code 1
>>>> LOG: terminating any other active server processes
>>>> WARNING: terminating connection because of crash of another server
>>>> process
>>>> DETAIL: The postmaster has commanded this server process to roll back
>>>> the
>>>> current transaction and exit, because another server process exited
>>>> abnormally and possibly corrupted shared memory.
>>>> HINT: In a moment you should be able to reconnect to the database and
>>>> repeat your command.
>>>> LOG: all server processes terminated; reinitializing
>>>> 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
>>>> LOG: database system was interrupted; last known up at 2015-07-17
>>>> 09:18:10
>>>> CEST
>>>> LOG: redo starts at 16/9F000028
>>>> LOG: record with zero length at 16/9F000100
>>>> LOG: redo done at 16/9F0000C8
>>>> LOG: MultiXact member wraparound protections are now enabled
>>>> LOG: database system is ready to accept connections
>>>> LOG: autovacuum launcher started
>>>>
>>>> Can anyone help me to identify and to resolve this inconvenience?
>>>>
>>>> Thanks in advance.
>>>>
>>>> Meph
>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://postgresql.nabble.com/Backup-fatal-issue-tp5858258.html
>>>> Sent from the PostgreSQL - general mailing list archive at Nabble.com.
>>>>
>>>>
>>>> --
>>>> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
>>>> To make changes to your subscription:
>>>> http://www.postgresql.org/mailpref/pgsql-general
>>>>
>>>
>>>
>>>
>>> --
>>> *Melvin Davidson*
>>> I reserve the right to fantasize. Whether or not you
>>> wish to share my fantasy is entirely up to you.
>>>
>>
>>
>
>
> --
> *Melvin Davidson*
> I reserve the right to fantasize. Whether or not you
> wish to share my fantasy is entirely up to you.
>