Re: [SPAM] psql 9.3 automatic recovery in progress

I was on vacation, but the issue have the same behavior:

2016-10-10 07:50:09 PDT WARNING: terminating connection because of
crash of another server process
2016-10-10 07:50:09 PDT 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.
2016-10-10 07:50:09 PDT HINT: In a moment you should be able to
reconnect to the database and repeat your command.
2016-10-10 07:50:09 PDT WARNING: terminating connection because of
crash of another server process
2016-10-10 07:50:09 PDT 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.
2016-10-10 07:50:09 PDT HINT: In a moment you should be able to
reconnect to the database and repeat your command.
2016-10-10 07:50:09 PDT LOG: archiver process (PID 13066) exited with
exit code 1
2016-10-10 07:50:10 PDT LOG: all server processes terminated; reinitializing
2016-10-10 07:50:10 PDT LOG: connection received: host=192.168.2.6 port=37700
2016-10-10 07:50:10 PDT LOG: database system was interrupted; last
known up at 2016-10-10 07:49:15 PDT
2016-10-10 07:50:10 PDT FATAL: the database system is in recovery mode
2016-10-10 07:50:10 PDT LOG: connection received: host=192.168.2.6 port=37702
2016-10-10 07:50:10 PDT FATAL: the database system is in recovery mode
2016-10-10 07:50:15 PDT LOG: database system was not properly shut
down; automatic recovery in progress
2016-10-10 07:50:15 PDT LOG: redo starts at 517/C9000028
2016-10-10 07:50:15 PDT LOG: unexpected pageaddr 517/77000000 in log
segment 0000000100000517000000D2, offset 0
2016-10-10 07:50:15 PDT LOG: redo done at 517/D10000C8
2016-10-10 07:50:15 PDT LOG: last completed transaction was at log
time 2016-10-10 07:49:09.891669-07
2016-10-10 07:50:15 PDT LOG: connection received: host=192.168.2.6 port=37704
2016-10-10 07:50:15 PDT FATAL: the database system is in recovery mode
2016-10-10 07:50:15 PDT LOG: connection received: host=192.168.2.6 port=37706
2016-10-10 07:50:15 PDT FATAL: the database system is in recovery mode
2016-10-10 07:50:16 PDT LOG: MultiXact member wraparound protections
are now enabled
2016-10-10 07:50:16 PDT LOG: database system is ready to accept connections
2016-10-10 07:50:16 PDT LOG: autovacuum launcher started

2016-10-10 09:00:01 PDT LOG: archiver process (PID 14004) exited with
exit code 1
2016-10-10 09:00:01 PDT WARNING: terminating connection because of
crash of another server process
2016-10-10 09:00:01 PDT 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.
2016-10-10 09:00:01 PDT HINT: In a moment you should be able to
reconnect to the database and repeat your command.
2016-10-10 09:00:01 PDT WARNING: terminating connection because of
crash of another server process
2016-10-10 09:00:01 PDT 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.
2016-10-10 09:00:01 PDT HINT: In a moment you should be able to
reconnect to the database and repeat your command.
2016-10-10 09:00:01 PDT LOG: all server processes terminated; reinitializing
2016-10-10 09:00:02 PDT LOG: database system was interrupted; last
known up at 2016-10-10 08:59:33 PDT
2016-10-10 09:00:03 PDT LOG: connection received: host=127.0.0.1 port=35950
2016-10-10 09:00:03 PDT FATAL: the database system is in recovery mode
2016-10-10 09:00:03 PDT LOG: connection received: host=127.0.0.1 port=35951
2016-10-10 09:00:03 PDT FATAL: the database system is in recovery mode
2016-10-10 09:00:03 PDT LOG: connection received: host=127.0.0.1 port=35952
2016-10-10 09:00:03 PDT FATAL: the database system is in recovery mode
2016-10-10 09:00:03 PDT LOG: connection received: host=127.0.0.1 port=35953
2016-10-10 09:00:03 PDT FATAL: the database system is in recovery mode
2016-10-10 09:00:03 PDT LOG: connection received: host=127.0.0.1 port=35954
2016-10-10 09:00:03 PDT FATAL: the database system is in recovery mode
2016-10-10 09:00:03 PDT LOG: connection received: host=127.0.0.1 port=35955
2016-10-10 09:00:03 PDT FATAL: the database system is in recovery mode
2016-10-10 09:00:05 PDT LOG: connection received: host=192.168.2.6 port=39380
2016-10-10 09:00:05 PDT FATAL: the database system is in recovery mode
2016-10-10 09:00:05 PDT LOG: connection received: host=192.168.2.6 port=39382
2016-10-10 09:00:05 PDT FATAL: the database system is in recovery mode
2016-10-10 09:00:07 PDT LOG: database system was not properly shut
down; automatic recovery in progress
2016-10-10 09:00:07 PDT LOG: redo starts at 51A/82000028
2016-10-10 09:00:07 PDT LOG: record with zero length at 51A/8E0126B0
2016-10-10 09:00:07 PDT LOG: redo done at 51A/8E012680
2016-10-10 09:00:07 PDT LOG: last completed transaction was at log
time 2016-10-10 09:00:01.142505-07
2016-10-10 09:00:08 PDT LOG: connection received: host=127.0.0.1 port=35956
2016-10-10 09:00:08 PDT FATAL: the database system is in recovery mode
2016-10-10 09:00:08 PDT LOG: connection received: host=127.0.0.1 port=35957
2016-10-10 09:00:08 PDT FATAL: the database system is in recovery mode
2016-10-10 09:00:08 PDT LOG: MultiXact member wraparound protections
are now enabled
2016-10-10 09:00:08 PDT LOG: database system is ready to accept connections
2016-10-10 09:00:08 PDT LOG: autovacuum launcher started

Thanks.

On Mon, Oct 10, 2016 at 11:32 AM, Adrian Klaver
<adrian(dot)klaver(at)aklaver(dot)com> wrote:
> On 10/10/2016 11:14 AM, Moreno Andreo wrote:
>>
>>
>> Il 10/10/2016 18:24, Periko Support ha scritto:
>>>
>>> 2016-09-12 09:00:01 PDT LOG: server process (PID 23958) was
>>> terminated by signal 9: Killed
>>
>>
>>> 2016-09-12 10:00:01 PDT LOG: server process (PID 30766) was
>>> terminated by signal 9: Killed
>>
>>
>>> 2016-09-12 15:00:01 PDT LOG: server process (PID 22030) was
>>> terminated by signal 9: Killed
>>>
>>>
>> These datetimes could be suspect. Every crash (kill) is done at
>> "00"minutes and "01" minutes, that makes me ask "Isn't there something
>> like cron running something that interfere with postgres?"
>
>
> While we on the subject, the datetimes are almost a month old.
>
> Does that mean this problem was just noticed or are the datetimes wrong?
>
>>
>> Cheers,
>> Moreno.
>>
>>
>>
>>
>
>
> --
> Adrian Klaver
> adrian(dot)klaver(at)aklaver(dot)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