<div dir="ltr"><div dir="ltr"><div>Hi Luca,</div><div><br></div><div>From what I understand from the logs you attached, the most likely scenario is a failure at OS level, which made the Postmaster process crash, probably</div><div>stopped by the OS itself with an OOM kill.</div><div><br></div><div>This is compatible with what is said here (the postmaster process received a Signal 9, a forced kill):<br><span style="font-family:monospace">2021-01-27 07:06:02.165 CET [582] LOG:  Serverprozess (PID 10391) wurde <br>
von Signal 9 beendet: Getötet</span></div><div><br></div><div>The child process which effectively triggered the issue is the backend which was running the update:<br><span style="font-family:monospace">2021-01-27 07:06:02.165 CET [582] DETAIL:  Der fehlgeschlagene Prozess <br>
führte aus: UPDATE city_boundaries SET way = <br>
ST_Makevalid(ST_Multi(ST_Buffer(ST_Buffer(way, 300, 'join=miter'), -300, <br>
'join=miter')));</span></div><div><br></div><div>For the following reason (memory corruption):<br><span style="font-family:monospace">2021-01-27 07:06:02.179 CET [10238] postgres@gis DETAIL:  Der Postmaster <br>
hat diesen Serverprozess angewiesen, die aktuelle Transaktion <br>
zurückzurollen und die Sitzung zu beenden, weil ein anderer <br>
Serverprozess abnormal beendet wurde und möglicherweise das Shared <br>
Memory verfälscht hat.</span></div><div><br></div><div>This made the PostgreSQL server restart in recovery mode:<br><span style="font-family:monospace">2021-01-27 07:06:03.208 CET [10411] postgres@gis FATAL:  das <br>
Datenbanksystem ist im Wiederherstellungsmodus</span></div><div><br></div><div>In the recovery mode, it started using the WALs available on the local storage to recover from the crash:<br><span style="font-family:monospace">2021-01-27 07:06:03.937 CET [10410] LOG:  Redo beginnt bei 11F/22E1D520<br>
2021-01-27 07:06:04.317 CET [10410] LOG:  ungültige Datensatzlänge bei <br>
11F/24124828: 24 erwartet, 0 erhalten<br>
2021-01-27 07:06:04.317 CET [10410] LOG:  Redo fertig bei 11F/241247F0</span></div><div><br></div><div>There's effectively a "warning" message about an issue in applying a specific location of the WALs (11F/24124828),</div><div>but I would avoid to focus for the moment on this, because it's a symptom of the real issue that made PostgreSQL crash,</div><div>not the origin. It was then able to properly restart:<br><span style="font-family:monospace">2021-01-27 07:06:05.597 CET [582] LOG:  Datenbanksystem ist bereit, um <br>
Verbindungen anzunehmen</span></div><div><br></div><div>To have a confirmation about the source of the issue, I'd suggest to have a look at system logs (syslog, dmesg, ...). I am</div><div>expecting some entry related to an OOM kill performed by the OS.</div><div><br></div><div>If this is confirmed, then the solution would be to check the configuration of PostgreSQL, OS, hardware (specially RAM resources), etc.<br></div><div><br></div><div>Also the fact that the transaction worked properly on a reduced dataset makes me think of a problem related to the size/complexity of the dataset,</div><div>with an undersized configuration of the whole DB server.</div><div><br></div><div>Hope it helps,</div><div>Giuseppe.<br></div></div></div>