Sql error 57p03 fatal the database system is in recovery mode

PostgreSQL 11: Ошибка [57P03]: FATAL: система базы данных находится в режиме восстановления

Я пытаюсь получить plpython3u язык, работающий в PostgreSQL 11 (я работаю на машине с Windows 10).

Мне удалось успешно установить его, используя следующую команду.

Мне пришлось скачать python36.dll и сохраните это в C:WindowsSystem32 чтобы успешно выполнить это, потому что раньше я получал следующую ошибку.

не удалось загрузить библиотеку «C:/Program Files/PostgreSQL/11/lib/plpython3.dll»: указанный модуль не может быть найден.

Чтобы протестировать установку, я попытался создать следующую функцию, которую я получил из документации PostgreSQL.

Но его выполнение дает мне следующую ошибку.

Ошибка SQL [57P03]: FATAL: система базы данных находится в режиме восстановления

Вот что я получил из журналов.

Любая помощь будет оценена по достоинству.

2 ответа

Мне пришлось скачать python36.dll и сохраните это в C:WindowsSystem32

Из-за отсутствия управления версиями библиотеки, того факта, что каталог, содержащий исполняемый файл, всегда находится на пути к разделяемой библиотеке, и вытекающей из этого небрежной привычки хранить случайные копии одной и той же разделяемой библиотеки в различных каталогах, пользователи Windows приобрели привычку загружать исполняемый файл. код откуда-то в Интернете и запускает его.

Это опасная и вредная практика. Очевидно, вы ошиблись инкарнацией разделяемой библиотеки Python или вам не хватает некоторых других важных файлов, и, как следствие, PostgreSQL вылетел при его использовании.

Удалите все файлы DLL из мошеннических загрузок, получите установочный пакет Python 3 и установите его обычным способом.

Как предположил в своем ответе Laurenz Albe, ошибка, скорее всего, была вызвана загруженным мной файлом DLL.

Я следил за этим.

1. Отбросьте расширение, используя DROP EXTENSION plpython3u
2. Удалите скачанный python36.dll от C:WindowsSystem32
3. Удалите все установленные версии Python на моем компьютере
4. Скачал и установил (для всех пользователей) 64-битную версию Python 3.6 (потому что это то, что plpython3.dll ожидал)
5. Добавлен путь Python к переменной Path переменных среды (я сделал это во время установки Python)
6. Снова установите расширение, используя CREATE EXTENSION plpython3u (удалось успешно создать расширение)

Я смог успешно протестировать это, используя следующий пример функции.

Источник

Русские Блоги

PSQL: Fatal: система баз данных находится в режиме восстановления — метод позиционирования проблемы и решение

Сначала введите фон, при тестировании базы данных Deepgreen (GreenPlum Upgrade), Pgbench устанавливается слишком много, вызывая умирающую карту базы данных, при подключении, перезапуска, выключении, все сообщите ту же ошибку: PSQL: Fatal: система базы данных в режиме восстановления. Поэтому попробуйте сделать это, решить проблему, общие шаги:

• 1. Попробуйте войти в базу данных, ошибку;
• 2. Просмотр процесса Postgres на мастере, найденный с ждет обновления, указывая на то, что на сегменте все еще есть операция;
• 3, 4, 5, 6. Просмотр процесса Postgres из четырех сегментных узлов, см. Множество операций PGBENCH IDLE в транзакции, просто определите, что эти операции не работали, но они все еще в транзакции, а не обрабатываются );
• 7. Отслеживайте один процесс через stroace и найдите, что нет работы;
• 8. Все операция PGBENCENCE на мастере и сегменте убивает все; перезапустите базу данных и решите проблему.

Конкретная операция заключается в следующем:

Интеллектуальная рекомендация

Реализация оценки приложения iOS

Есть два способа получить оценку приложения: перейти в App Store для оценки и оценка в приложении. 1. Перейдите в App Store, чтобы оценить ps: appid можно запросить в iTunes Connect 2. Встроенная оцен.

JS функциональное программирование (е)

Давайте рассмотрим простой пример, чтобы проиллюстрировать, как используется Reduce. Первый параметр Reduce — это то, что мы принимаем массив arrayOfNums, а второй параметр — функцию. Эта функция прин.

PWN_JarvisOJ_Level1

Nc первый Затем мы смотрим на декомпиляцию ida Перед «Hello, World! N» есть уязвимая_функция, проверьте эту функцию после ввода Видно, что только что появившийся странный адрес является пе.

Установка и развертывание Kubernetes

На самом деле, я опубликовал статью в этом разделе давным -давно, но она не достаточно подробно, и уровень не является ясным. Когда я развернулся сегодня, я увидел его достаточно (хотя это было успешн.

На стороне многопроцессорного сервера — (2) *

Обработка сигнала Родительский процесс часто очень занят, поэтому вы не можете просто вызвать функцию waitpid, чтобы дождаться завершения дочернего процесса. Затем обсудите решение. Обратитесь .

Источник

PostgreSQL 11: Ошибка [57P03]: FATAL: система базы данных находится в режиме восстановления

Я пытаюсь заставить plpython3u язык работать в PostgreSQL 11 (я работаю на машине с Windows 10 ).

Мне удалось успешно установить его, используя следующую команду.

Мне пришлось загрузить python36.dll и сохранить его, C:WindowsSystem32 чтобы успешно выполнить это, потому что раньше я получал следующую ошибку.

could not load library «C:/Program Files/PostgreSQL/11/lib/plpython3.dll»: The specified module could not be found.

Чтобы проверить установку, я попытался создать следующую функцию, которую я получил из документации PostgreSQL .

Но его выполнение дает мне следующую ошибку.

SQL Error [57P03]: FATAL: the database system is in recovery mode

Вот что я получил из журналов.

Любая помощь будет оценена по достоинству.

I had to download python36.dll and save it in C:WindowsSystem32

Из-за отсутствия управления версиями библиотек, того факта, что каталог, содержащий исполняемый файл, всегда находится на пути к общей библиотеке, и вытекающей из этого небрежной привычки хранить случайные копии одной и той же общей библиотеки в разных каталогах, пользователи Windows приобрели привычку загружать исполняемый файл. код откуда-то в Интернете и запускает его.

Это опасная и вредная практика. Очевидно, вы ошиблись инкарнацией разделяемой библиотеки Python или вам не хватает некоторых других важных файлов, и, как следствие, PostgreSQL аварийно завершил работу при его использовании.

Удалите все файлы DLL из незаконных загрузок, получите установочный пакет Python 3 и установите его обычным способом.

Источник

Re: Why is my Postgre server went in recovery mode all in sudden

1) What OS and version?

ans: windows 2012R2

2) System memory size is ?

3) What is session_start_timestamp tracking? In other words what does it
match up to here:
ans: This is the format to
timestamp=%m,user=%u,db=%d,app=%a,client=%h,transaction-
ID=%x,session_start_timestamp=%s,SQL_state=%e
The time when the session is session_started _start_timestamp

4) What is the process that started 2018-04-26 10:08:19?

ans: Its an backed process of Postgre started parallel worker

5) The query in the log started at 2018-05-07 00:32:46, what is it doing?
ans : query running from an agent if any processing is going on the front
end some of the query will run

On Thu, May 10, 2018 at 5:10 AM, Adrian Klaver
wrote:

Источник

gp 5.0.0 issue with recovery mode #8333

Recently I have a problem with gp 5.0. GP shows «the database system is in recovery mode» when I access it.
Here’s some logs in pg_log

Sometimes the same problem occured but it recovered itself (below)

I always killed the postgres process and restarted it when it occured and can not recover itself. It is useful but it won’t take long.This issue occurs frequently.I guess it’s an issue of lwlock. Is it a version problem?

The core dump file can be obtained as below
https://share.weiyun.com/533ip2X passward：sa45jv

Any help will be helpful for us.

The text was updated successfully, but these errors were encountered:

Can you describe more about what you mean when you say «when I access it». Are you using psql, and that’s when this error occurs?

It looks like something is sending an abort signal to the postmaster.

Would you provide the exact version of GPDB5 you’re using:

When I using psql: ‘psql -d postgres’, it returns»psql: FATAL: the database system is in recovery mode».

select version();
PostgreSQL 8.3.23 (Greenplum Database 5.0.0 build dev) on x86_64-pc-l
inux-gnu, compiled by GCC gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-4),
64-bit compiled on May 27 2018 19:58:48

There are some other information in the log, I don’t know if it has any effect.

2019-08-19 08:43:04.209975 CST,»aysadmin»,»postgres»,p15928,th1704298560,»192.168.244.200″,»41234″,2019-08-19 08:43:02 CST,0,con60730,cmd3,seg-1,,dx149855,,sx1,»LOG»,»00000″,»Process interrupt for ‘query cancel pending’ (postgres.c:3503)». «select version()»,0,,»postgres.c»,3670, 2019-08-19 08:43:04.210169 CST,»aysadmin»,»postgres»,p15928,th1704298560,»192.168.244.200″,»41234″,2019-08-19 08:43:02 CST,0,con60730,cmd3,seg-1,,dx149855,,sx1,»ERROR»,»57014″,»canceling statement due to user request». «select version()»,0,,»postgres.c»,3709, 2019-08-19 08:43:04.210197 CST,»aysadmin»,»postgres»,p15928,th1704298560,»192.168.244.200″,»41234″,2019-08-19 08:43:02 CST,0,con60730,cmd3,seg-1,,dx149855,,sx1,»LOG»,»00000″,»An exception was encountered during the execution of statement: select version()». 0. 2019-08-19 08:43:04.269456 CST,»aysadmin»,»postgres»,p15937,th1704298560,»192.168.244.200″,»41243″,2019-08-19 08:43:03 CST,0,con60732,cmd1,seg-1,,dx149856,,sx1,»LOG»,»00000″,»Process interrupt for ‘query cancel pending’ (postgres.c:3503)». «select version()»,0,,»postgres.c»,3670, 2019-08-19 08:43:04.269766 CST,»aysadmin»,»postgres»,p15937,th1704298560,»192.168.244.200″,»41243″,2019-08-19 08:43:03 CST,0,con60732,cmd1,seg-1,,dx149856,,sx1,»ERROR»,»57014″,»canceling statement due to user request». «select version()»,0,,»postgres.c»,3709, 2019-08-19 08:43:04.269796 CST,»aysadmin»,»postgres»,p15937,th1704298560,»192.168.244.200″,»41243″,2019-08-19 08:43:03 CST,0,con60732,cmd1,seg-1,,dx149856,,sx1,»LOG»,»00000″,»An exception was encountered during the execution of statement: select version()». 0. 2019-08-19 08:43:04.287210 CST,»aysadmin»,»postgres»,p15937,th1704298560,»192.168.244.200″,»41243″,2019-08-19 08:43:03 CST,0,con60732,cmd2,seg-1,,dx149860,,sx1,»LOG»,»00000″,»execute : SHOW TRANSACTION ISOLATION LEVEL». «SHOW TRANSACTION ISOLATION LEVEL»,0,,»postgres.c»,2740, 2019-08-19 08:43:04.289980 CST,»aysadmin»,»postgres»,p15931,th1704298560,»192.168.244.200″,»41236″,2019-08-19 08:43:02 CST,0,con60731,cmd3,seg-1,,dx149858,,sx1,»LOG»,»00000″,»Process interrupt for ‘query cancel pending’ (postgres.c:3503)». «select version()»,0,,»postgres.c»,3670, 2019-08-19 08:43:04.290008 CST,»aysadmin»,»postgres»,p15931,th1704298560,»192.168.244.200″,»41236″,2019-08-19 08:43:02 CST,0,con60731,cmd3,seg-1,,dx149858,,sx1,»ERROR»,»57014″,»canceling statement due to user request». «select version()»,0,,»postgres.c»,3709, 2019-08-19 08:43:04.290032 CST,»aysadmin»,»postgres»,p15931,th1704298560,»192.168.244.200″,»41236″,2019-08-19 08:43:02 CST,0,con60731,cmd3,seg-1,,dx149858,,sx1,»LOG»,»00000″,»An exception was encountered during the execution of statement: select version()». 0. 2019-08-19 08:43:04.354624 CST,»aysadmin»,»postgres»,p15941,th1704298560,»192.168.244.200″,»41245″,2019-08-19 08:43:03 CST,0,con60733,cmd1,seg-1,,dx149859,,sx1,»LOG»,»00000″,»Process interrupt for ‘query cancel pending’ (postgres.c:3503)». «select version()»,0,,»postgres.c»,3670, 2019-08-19 08:43:04.354662 CST,»aysadmin»,»postgres»,p15941,th1704298560,»192.168.244.200″,»41245″,2019-08-19 08:43:03 CST,0,con60733,cmd1,seg-1,,dx149859,,sx1,»ERROR»,»57014″,»canceling statement due to user request». «select version()»,0,,»postgres.c»,3709, 2019-08-19 08:43:04.354683 CST,»aysadmin»,»postgres»,p15941,th1704298560,»192.168.244.200″,»41245″,2019-08-19 08:43:03 CST,0,con60733,cmd1,seg-1,,dx149859,,sx1,»LOG»,»00000″,»An exception was encountered during the execution of statement: select version()». 0. 2019-08-19 08:43:04.373566 CST,»aysadmin»,»postgres»,p15941,th1704298560,»192.168.244.200″,»41245″,2019-08-19 08:43:03 CST,0,con60733,cmd2,seg-1,,dx149863,,sx1,»LOG»,»00000″,»execute : SHOW TRANSACTION ISOLATION LEVEL». «SHOW TRANSACTION ISOLATION LEVEL»,0,,»postgres.c»,2740, 2019-08-19 08:43:05.329128 CST,»aysadmin»,»postgres»,p15937,th1704298560,»192.168.244.200″,»41243″,2019-08-19 08:43:03 CST,0,con60732,cmd3,seg-1,,dx149861,,sx1,»LOG»,»00000″,»Process interrupt for ‘query cancel pending’ (postgres.c:3503)». «select version()»,0,,»postgres.c»,3670,

5.0.0 is very old version. Please can you try out the latest 5.0 version and see if the same problem is faced. If facing the same problem on recent versions of 5.0, please help us with repro steps so that we can help on the RCA and fix if required. I am closing this issue for now, as no next action. Please feel free to re-open the issue if faced on recent versions.

Источник

Relevant system information:

• OS: x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36), 64-bit
  Running on Win10 in a Virtualbox VM

• PostgreSQL version (output of postgres --version): PostgreSQL 11.2

• TimescaleDB version (output of dx in psql): 1.2.1

• Installation method: vagrant (scripts attached)

Describe the bug
Conversion of a table into a hypertable using SQL from a JDBC DB Client yields a SQL error and database crash. After this the database is restarting, recovering and available.

To Reproduce

1. Create Table

create table bigtable as 
select 
  cast (generate_series as bigint) id
  , trunc(generate_series / 1000) id1
  , mod(generate_series, 1000) id2
  , 'bigtable row: ' || generate_series as row_desc
from 
generate_series(1,1e7);

1. Migrate to hypertable

SELECT create_hypertable('bigtable', 'id', migrate_data => true, chunk_time_interval => 1);

Expected behavior
Conversion should finish appropriately. If the table is large it should process the migration in chunks without out of memory issues.

Actual behavior
Execution of step 2 aborts with error message:

SQL Error [57P03]: FATAL: the database system is in recovery mode
  FATAL: the database system is in recovery mode
  FATAL: the database system is in recovery mode

Database is crashing and restarts with recovery. The recovery is ending successfully and the database is available again without having the table migrated.

Logs
Log output: postgresql-Tue.log

2019-03-12 09:13:25.838 CET [6213] FATAL:  the database system is in recovery mode
2019-03-12 09:13:25.845 CET [6214] FATAL:  the database system is in recovery mode
2019-03-12 09:13:25.919 CET [6215] FATAL:  the database system is in recovery mode
2019-03-12 09:13:25.927 CET [6216] FATAL:  the database system is in recovery mode
2019-03-12 09:13:32.863 CET [6209] LOG:  database system was not properly shut down; automatic recovery in progress
2019-03-12 09:13:32.868 CET [6209] LOG:  redo starts at 0/17DE420
2019-03-12 09:14:15.441 CET [6209] LOG:  redo done at 0/7CFFFF88
2019-03-12 09:14:15.441 CET [6209] LOG:  last completed transaction was at log time 2019-03-12 09:12:34.219298+01
2019-03-12 09:14:23.813 CET [6111] LOG:  database system is ready to accept connections
2019-03-12 09:14:23.813 CET [6222] LOG:  TimescaleDB background worker launcher connected to shared catalogs

Additional context
install_postgres.sh.txt
install_timescale.sh.txt

1) What OS and version?

ans: windows 2012R2

2) System memory size is ?

ans: 32GB

3) What is session_start_timestamp tracking? In other words what does it
match up to here:
ans: This is the format to
timestamp=%m,user=%u,db=%d,app=%a,client=%h,transaction-
ID=%x,session_start_timestamp=%s,SQL_state=%e
The time when the session is session_started _start_timestamp

4) What is the process that started 2018-04-26 10:08:19?

ans: Its an backed process of Postgre started parallel worker

5) The query in the log started at 2018-05-07 00:32:46, what is it doing?
ans : query running from an agent if any processing is going on the front
end some of the query will run

On Thu, May 10, 2018 at 5:10 AM, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
wrote:

> On 05/09/2018 11:31 AM, nikhil raj wrote:
>
>> Hi Team,
>>
>> I dont have any idea why did my Postgres server crash and it says
>>
>> timestamp=2018-05-07 00:34:11.209 EDT,user=,db=,app=,client=,tra
>> nsaction-ID=0,session_start_timestamp=2018-04-26 10:08:19
>> EDT,SQL_state=00000LOG: worker process: parallel worker for PID 2864 (PID
>> 4476) exited with exit code 0
>> timestamp=2018-05-07 00:34:11.209 EDT,user=,db=,app=,client=,tra
>> nsaction-ID=0,session_start_timestamp=2018-04-26 10:08:19
>> EDT,SQL_state=00000LOG: terminating any other active server processes
>> timestamp=2018-05-07 00:34:11.209 EDT,user=postgres,db=Ozalo,app
>> =[unknown],transaction-ID=0,session_start_timestamp=2018-05-07 00:32:46
>> EDT,SQL_state=00000LOG: duration: 0.331 ms bind <unnamed>: SELECT
>> «repository».»c_token» AS «token», «repository».»c_path» AS «path»
>>
>> FROM
>>
>> t_e20so1_repository AS «repository» INNER JOIN
>> t_e20so1_document_bigint AS «documentbigint» ON
>> «repository».»c_repositoryid» = «documentbigint».»c_value»
>>
>> WHERE «documentbigint».»c_documentid» = 201989
>>
>> AND «documentbigint».»c_fieldid» = ‘b035afc8-439f-4f2c-a9ae-e0540
>> 52511fd’
>> timestamp=2018-05-07 00:34:11.210 EDT,user=postgres,db=
>> Ozalo,app=[unknown],transaction-ID=0,session_start_timestamp=2018-05-07
>> 00:32:46 EDT,SQL_state=00000LOG: duration: 0.061 ms execute <unnamed>:
>> SELECT «repository».»c_token» AS «token», «repository».»c_path» AS «path»
>> FROM
>> t_zs01_sys_dm AS «repository» INNER JOIN t_e20so1_document_bigint AS
>> «documentbigint» ON «repository».»c_repositoryid» =
>> «documentbigint».»c_value»
>> WHERE «documentbigint».»c_documentid» = 201989
>> AND «documentbigint».»c_fieldid» = ‘b035afc8-439f-4f2c-a9ae-e0540
>> 52511fd’
>>
>>
>> after Some time i was receiving this error
>>
>>
>> timestamp=2018-05-07 00:34:11.218 EDT,user=postgres,db= Ozalo
>> ,app=[unknown],transaction-ID=0,session_start_timestamp=2018-05-07
>> 00:34:10 EDT,SQL_state=57P02WARNING: terminating connection because of
>> crash of another server process
>> timestamp=2018-05-07 00:34:11.218 EDT,user=postgres,db= Ozalo
>> ,app=[unknown],transaction-ID=0,session_start_timestamp=2018-05-07
>> 00:34:10 EDT,SQL_state=57P02DETAIL: 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.
>> timestamp=2018-05-07 00:34:11.218 EDT,user=postgres,db= Ozalo
>> ,app=[unknown],transaction-ID=0,session_start_timestamp=2018-05-07
>> 00:34:10 EDT,SQL_state=57P02HINT: In a moment you should be able to
>> reconnect to the database and repeat your command.
>>
>> timestamp=2018-05-07 00:34:11.357 EDT,user=,db=,app=,client=,tra
>> nsaction-ID=0,session_start_timestamp=2018-04-26 10:08:20
>> EDT,SQL_state=57P02DETAIL: 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.
>> timestamp=2018-05-07 00:34:11.357 EDT,user=,db=,app=,client=,tra
>> nsaction-ID=0,session_start_timestamp=2018-04-26 10:08:20
>> EDT,SQL_state=57P02HINT: In a moment you should be able to reconnect to
>> the database and repeat your command.
>> timestamp=2018-05-07 00:34:11.379 EDT,user=postgres,db=
>> Ozalo,app=[unknown],,transaction-ID=0,session_start_timestamp=2018-05-07
>> 00:34:11 EDT,SQL_state=57P03FATAL: the database system is in recovery mode
>> timestamp=2018-05-07 00:34:11.381 EDT,user=postgres,db=
>> Ozalo,app=[unknown],transaction-ID=0,session_start_timestamp=2018-05-07
>> 00:34:11 EDT,SQL_state=57P03FATAL: the database system is in recovery mode
>>
>>
>>
>> what is the reason it corrupted share memory ?
>>
>
> At this point I don’t know. More information is required:
>
> 1) What OS and version?
>
> 2) System memory size is ?
>
> 3) Where was Postgres installed from?
>
> 4) What is session_start_timestamp tracking? In other words what does it
> match up to here:
>
> https://www.postgresql.org/docs/10/static/runtime-config-logging.html
>
> log_line_prefix
>
> 5) What is the process that started 2018-04-26 10:08:19?
>
> 6) The query in the log started at 2018-05-07 00:32:46, what is it doing?
>
>
>
>
>> what is meant by 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. ?
>> how much of share memory if its consume it will crash
>>
>> Please can any one help me in this
>> or else what is the reason of crash of DB server
>>
>> Current using 10.3
>> |
>> Current Config
>>
>> max_connections = 5000||
>> shared_buffers = 7680MB ||||
>> effective_cache_size = 23040MB |||
>>
>> |maintenance_work_mem = 1920MB min_wal_size = 1GB max_wal_size = 2GB
>> checkpoint_completion_target = 0.7 wal_buffers = 16MB
>> default_statistics_target = 100 random_page_cost = 1.1
>> effective_io_concurrency = 200 max_worker_processes = 16
>> max_parallel_workers_per_gather = 8 max_parallel_workers = 16 work_mem =
>> 196kB|
>>
>>
>>
>> Thanks
>>
>>
>>
>
> —
> Adrian Klaver
> adrian(dot)klaver(at)aklaver(dot)com
>

Hello everyone,I have an application that uses Postgresql, lately randomly I find the database in recovery mode…

Here are the logs:

2020-08-09 14:42:03 UTC [5241-1] [unknown]@[unknown] FATAL:  unsupported frontend protocol 65363.19778: server supports 1.0 to 3.0
2020-08-09 17:08:52 UTC [13402-1] [unknown]@[unknown] LOG:  could not accept SSL connection: EOF detected
2020-08-10 08:30:19 UTC [30275-1] root@root FATAL:  no pg_hba.conf entry for host "183.136.225.44", user "root", database "root", SSL off
2020-08-10 14:19:55 UTC [2361-2] WARNING:  worker took too long to start; canceled
2020-08-10 14:20:51 UTC [6860-1] WARNING:  autovacuum worker started without a worker entry
2020-08-10 14:34:47 UTC [2361-3] WARNING:  worker took too long to start; canceled
2020-08-10 14:41:19 UTC [6930-1] WARNING:  autovacuum worker started without a worker entry
2020-08-10 14:43:22 UTC [2191-5] LOG:  checkpointer process (PID 2358) was terminated by signal 9: Killed
2020-08-10 14:46:25 UTC [2191-6] LOG:  terminating any other active server processes
2020-08-10 14:49:18 UTC [2191-7] LOG:  statistics collector process (PID 2362) was terminated by signal 9: Killed
2020-08-10 14:49:20 UTC [2191-8] LOG:  all server processes terminated; reinitializing
2020-08-10 14:49:26 UTC [7100-1] LOG:  database system was interrupted; last known up at 2020-08-10 14:25:15 UTC
2020-08-10 14:49:26 UTC [7101-1] intacloud@struttura FATAL:  the database system is in recovery mode
2020-08-10 14:49:26 UTC [7102-1] intacloud@struttura FATAL:  the database system is in recovery mode
2020-08-10 14:49:26 UTC [7103-1] intacloud@struttura FATAL:  the database system is in recovery mode
2020-08-10 14:49:26 UTC [7104-1] intacloud@struttura FATAL:  the database system is in recovery mode
2020-08-10 14:49:27 UTC [7106-1] intacloud@struttura FATAL:  the database system is in recovery mode
2020-08-10 14:49:27 UTC [7105-1] intacloud@struttura FATAL:  the database system is in recovery mode
2020-08-10 14:49:27 UTC [7113-1] intacloud@struttura FATAL:  the database system is in recovery mode
2020-08-10 14:49:27 UTC [7114-1] intacloud@struttura FATAL:  the database system is in recovery mode
2020-08-10 14:49:38 UTC [7100-2] LOG:  database system was not properly shut down; automatic recovery in progress
2020-08-10 14:49:38 UTC [7100-3] LOG:  invalid record length at 5B/D261FE28
2020-08-10 14:49:38 UTC [7100-4] LOG:  redo is not required
2020-08-10 14:49:39 UTC [7100-5] LOG:  MultiXact member wraparound protections are now enabled
2020-08-10 14:49:39 UTC [2191-9] LOG:  database system is ready to accept connections
2020-08-10 14:49:39 UTC [7133-1] LOG:  autovacuum launcher started
2020-08-10 14:53:57 UTC [2062-1] LOG:  could not bind IPv4 socket: Address already in use
2020-08-10 14:53:57 UTC [2062-2] HINT:  Is another postmaster already running on port 5432? If not, wait a few seconds and retry.
2020-08-10 14:53:57 UTC [2062-3] WARNING:  could not create listen socket for "localhost"
2020-08-10 14:53:58 UTC [2265-1] [unknown]@[unknown] LOG:  incomplete startup packet
2020-08-10 14:53:58 UTC [2264-1] LOG:  database system was interrupted; last known up at 2020-08-10 14:49:39 UTC
2020-08-10 14:53:58 UTC [2266-1] postgres@postgres FATAL:  the database system is starting up
2020-08-10 14:53:59 UTC [2284-1] postgres@postgres FATAL:  the database system is starting up
2020-08-10 14:53:59 UTC [2294-1] postgres@postgres FATAL:  the database system is starting up
2020-08-10 14:54:00 UTC [2307-1] postgres@postgres FATAL:  the database system is starting up
2020-08-10 14:54:01 UTC [2311-1] postgres@postgres FATAL:  the database system is starting up
2020-08-10 14:54:01 UTC [2318-1] postgres@postgres FATAL:  the database system is starting up
2020-08-10 14:54:02 UTC [2326-1] postgres@postgres FATAL:  the database system is starting up
2020-08-10 14:54:02 UTC [2333-1] postgres@postgres FATAL:  the database system is starting up
2020-08-10 14:54:03 UTC [2343-1] postgres@postgres FATAL:  the database system is starting up
2020-08-10 14:54:03 UTC [2353-1] postgres@postgres FATAL:  the database system is starting up
2020-08-10 14:54:04 UTC [2356-1] postgres@postgres FATAL:  the database system is starting up
2020-08-10 14:54:04 UTC [2357-1] [unknown]@[unknown] LOG:  incomplete startup packet
2020-08-10 14:54:05 UTC [2264-2] LOG:  database system was not properly shut down; automatic recovery in progress
2020-08-10 14:54:05 UTC [2264-3] LOG:  invalid record length at 5B/D261FE98
2020-08-10 14:54:05 UTC [2264-4] LOG:  redo is not required
2020-08-10 14:54:06 UTC [2264-5] LOG:  MultiXact member wraparound protections are now enabled
2020-08-10 14:54:06 UTC [2062-4] LOG:  database system is ready to accept connections
2020-08-10 14:54:06 UTC [2433-1] LOG:  autovacuum launcher started

The database does not restart by itself.

Where can I start debugging this problem?

Thanks so much