<div><div><div>Good day to everyone!</div><div> </div><div>Last night I performed a switchover in the cluster.</div><div> </div><div>Today I tried to catch an error when updating 14.19 ==> 14.23 on the old primary, but everything worked as expected.</div><div>The database started and connected to the replication slot on the new primary.</div><div> </div><div>##STANDBY_LOG</div><div><div>2026-06-17 14:16:08.367 [18915] @ // |6a305dc8.49e3|:8 (0): > LOG: received fast shutdown request</div><div>2026-06-17 14:16:08.368 [18915] @ // |6a305dc8.49e3|:9 (0): > LOG: aborting any active transactions</div><div>...</div><div>2026-06-17 14:16:18.318 [19845] @ // |6a305dc9.4d85|:462 (0): > LOG: restartpoint complete: wrote 1352773 buffers (32.3%); 0 WAL file(s) added, 14 removed, 14 recycled; write=661.408 s, sync=1.035 s, total=663.019 s; sync files=1196, longest=0.039 s, average=0.001 s; distance=3668114 kB, estimate=5645168 kB</div><div>2026-06-17 14:16:18.318 [19845] @ // |6a305dc9.4d85|:463 (0): > LOG: recovery restart point at C326/AA442CA8</div><div>2026-06-17 14:16:18.318 [19845] @ // |6a305dc9.4d85|:464 (0): > DETAIL: Last completed transaction was at log time 2026-06-17 14:16:08.367471+03.</div><div>2026-06-17 14:16:18.320 [19845] @ // |6a305dc9.4d85|:465 (0): > LOG: shutting down</div><div>2026-06-17 14:16:18.386 [18915] @ // |6a305dc8.49e3|:10 (0): > LOG: database system is shut down</div><div>...</div><div>2026-06-17 14:33:58.250 [24198] @ // |6a3285e1.5e86|:4 (0):1/0 > LOG: consistent recovery state reached at C329/102596D0</div><div>2026-06-17 14:33:58.250 [24198] @ // |6a3285e1.5e86|:5 (0):1/0 > LOG: invalid record length at C329/102596D0: wanted 24, got 0</div><div>2026-06-17 14:33:58.251 [24195] @ // |6a3285e0.5e83|:7 (0): > LOG: database system is ready to accept read-only connections</div><div>2026-06-17 14:33:58.260 [24437] @ // |6a328626.5f75|:1 (0): > LOG: started streaming WAL from primary at C329/10000000 on timeline 7</div></div></div></div><div> </div><div><div>It doesn't seem to be a code error, but rather a configuration issue on the server itself.</div></div><div>Given that I cannot provide any additional information and was unable to reproduce the error, I would like to close the ticket.</div><div><div>Thank you for your response.</div></div><div> </div><div><div> </div><div>С уважением,</div><div>Сергей Дм. Апойченко.</div><div> </div></div><div> </div><div> </div><div> </div><div>----------------</div><div>Кому: Álvaro Herrera (<a href="mailto:alvherre(at)kurilemu(dot)de" rel="noopener noreferrer">alvherre(at)kurilemu(dot)de</a>);</div><div>Копия: PostgreSQL mailing lists (<a href="mailto:pgsql-bugs(at)lists(dot)postgresql(dot)org" rel="noopener noreferrer">pgsql-bugs(at)lists(dot)postgresql(dot)org</a>);</div><div>Тема: BUG #19521: After a minor PostgreSQL update from 14.22 to 14.23, the database goes into an infinite loop.;</div><div>16.06.2026, 23:43, "Andrey Borodin" <<a href="mailto:x4mmm(at)yandex-team(dot)ru" rel="noopener noreferrer">x4mmm(at)yandex-team(dot)ru</a>>:</div><blockquote><p><br /> </p><blockquote> On 16 Jun 2026, at 23:36, Álvaro Herrera <<a href="mailto:alvherre(at)kurilemu(dot)de" rel="noopener noreferrer">alvherre(at)kurilemu(dot)de</a>> wrote:<br /> <br /> On 2026-Jun-15, Andrey Borodin wrote:<br /> <blockquote><blockquote> On 15 Jun 2026, at 18:39, PG Bug reporting form <<a href="mailto:noreply(at)postgresql(dot)org" rel="noopener noreferrer">noreply(at)postgresql(dot)org</a>> wrote:<br /> <br /> After rolling back to version 14.22, everything works as intended.</blockquote> <br /> Hi! Thanks for the report. Can you please give a bit more logs? This excerpt is<br /> missing errors from the startup process. And message from this process could shed<br /> a light on a root cause.</blockquote> <br /> I suspect e35e466f61b [1] might be related. That's a bug that was<br /> fixed in 2bb60eb4fea [2], just after 14.23.<br /> <br /> [1] <a href="https://postgr.es/c/e35e466f61b" rel="noopener noreferrer">https://postgr.es/c/e35e466f61b</a><br /> [2] <a href="https://postgr.es/c/2bb60eb4fea" rel="noopener noreferrer">https://postgr.es/c/2bb60eb4fea</a><br /> <br /> If not, some data from pg_waldump around the problem area might be useful.</blockquote><p><br />Yeah, that was my concern. But that bug manifests as startup process failure.<br />I've contacted Sergey offlist, he observed hanging<br /><br />postgres: data: startup recovering 000000060000C29100000016<br /><br />so it's hard to tell what's going on without backtrace...<br /><br /><br />Best regards, Andrey Borodin.</p></blockquote>