Re: Backup fatal issue

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.