Good day to everyone!
 
Last night I performed a switchover in the cluster.
 
Today I tried to catch an error when updating 14.19 ==> 14.23 on the old primary, but everything worked as expected.
The database started and connected to the replication slot on the new primary.
 
##STANDBY_LOG
2026-06-17 14:16:08.367  [18915] @ //  |6a305dc8.49e3|:8 (0): > LOG:  received fast shutdown request
2026-06-17 14:16:08.368  [18915] @ //  |6a305dc8.49e3|:9 (0): > LOG:  aborting any active transactions
...
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
2026-06-17 14:16:18.318  [19845] @ //  |6a305dc9.4d85|:463 (0): > LOG:  recovery restart point at C326/AA442CA8
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.
2026-06-17 14:16:18.320  [19845] @ //  |6a305dc9.4d85|:465 (0): > LOG:  shutting down
2026-06-17 14:16:18.386  [18915] @ //  |6a305dc8.49e3|:10 (0): > LOG:  database system is shut down
...
2026-06-17 14:33:58.250  [24198] @ //  |6a3285e1.5e86|:4 (0):1/0 > LOG:  consistent recovery state reached at C329/102596D0
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
2026-06-17 14:33:58.251  [24195] @ //  |6a3285e0.5e83|:7 (0): > LOG:  database system is ready to accept read-only connections
2026-06-17 14:33:58.260  [24437] @ //  |6a328626.5f75|:1 (0): > LOG:  started streaming WAL from primary at C329/10000000 on timeline 7
 
It doesn't seem to be a code error, but rather a configuration issue on the server itself.
Given that I cannot provide any additional information and was unable to reproduce the error, I would like to close the ticket.
Thank you for your response.
 
 
С  уважением,
Сергей Дм. Апойченко.
 
 
 
 
----------------
Кому: Álvaro Herrera (alvherre@kurilemu.de);
Копия: PostgreSQL mailing lists (pgsql-bugs@lists.postgresql.org);
Тема: BUG #19521: After a minor PostgreSQL update from 14.22 to 14.23, the database goes into an infinite loop.;
16.06.2026, 23:43, "Andrey Borodin" <x4mmm@yandex-team.ru>:


 

 On 16 Jun 2026, at 23:36, Álvaro Herrera <alvherre@kurilemu.de> wrote:
 
 On 2026-Jun-15, Andrey Borodin wrote:
 
 On 15 Jun 2026, at 18:39, PG Bug reporting form <noreply@postgresql.org> wrote:
 
 After rolling back to version 14.22, everything works as intended.
 
 Hi! Thanks for the report. Can you please give a bit more logs? This excerpt is
 missing errors from the startup process. And message from this process could shed
 a light on a root cause.
 
 I suspect e35e466f61b [1] might be related. That's a bug that was
 fixed in 2bb60eb4fea [2], just after 14.23.
 
 [1] https://postgr.es/c/e35e466f61b
 [2] https://postgr.es/c/2bb60eb4fea
 
 If not, some data from pg_waldump around the problem area might be useful.


Yeah, that was my concern. But that bug manifests as startup process failure.
I've contacted Sergey offlist, he observed hanging

postgres: data: startup recovering 000000060000C29100000016

so it's hard to tell what's going on without backtrace...


Best regards, Andrey Borodin.