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 <mephystoonh...@gmail.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 <melvin6...@gmail.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 <mephystoonh...@gmail.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@postgresql.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.

Reply via email to