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.