BUG #19521: After a minor PostgreSQL update from 14.22 to 14.23, the database goes into an infinite loop.

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.

Best regards, Andrey Borodin.

On Mon, Jun 15, 2026 at 10:44:31PM +0500, Andrey Borodin wrote:

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.

Looking at the set of changes in the range REL_14_22..REL_14_23, we
don't have many things related to recovery, so if you can provide more
details we will likely be able to point to a cause. Without more
information there is nothing that we can unfortunately do.

One thing that I suspect is some custom extension code that may live
outside of core. I have not heard about cases similar to the one
here, and it's been more than 4 weeks since this 14.23 has been
released.
--
Michael

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]https://postgr.es/c/e35e466f61b might be related. That's a bug that was
fixed in 2bb60eb4fea [2]https://postgr.es/c/2bb60eb4fea, 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.

--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
"If you have nothing to say, maybe you need just the right tool to help you
not say it." (New York Times, about Microsoft PowerPoint)

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.

<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 ==&gt; 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): &gt; LOG:  received fast shutdown request</div><div>2026-06-17 14:16:08.368  [18915] @ //  |6a305dc8.49e3|:9 (0): &gt; LOG:  aborting any active transactions</div><div>...</div><div>2026-06-17 14:16:18.318  [19845] @ //  |6a305dc9.4d85|:462 (0): &gt; 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): &gt; LOG:  recovery restart point at C326/AA442CA8</div><div>2026-06-17 14:16:18.318  [19845] @ //  |6a305dc9.4d85|:464 (0): &gt; 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): &gt; LOG:  shutting down</div><div>2026-06-17 14:16:18.386  [18915] @ //  |6a305dc8.49e3|:10 (0): &gt; LOG:  database system is shut down</div><div>...</div><div>2026-06-17 14:33:58.250  [24198] @ //  |6a3285e1.5e86|:4 (0):1/0 &gt; LOG:  consistent recovery state reached at C329/102596D0</div><div>2026-06-17 14:33:58.250  [24198] @ //  |6a3285e1.5e86|:5 (0):1/0 &gt; 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): &gt; LOG:  database system is ready to accept read-only connections</div><div>2026-06-17 14:33:58.260  [24437] @ //  |6a328626.5f75|:1 (0): &gt; 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@kurilemu.de" rel="noopener noreferrer">alvherre@kurilemu.de</a>);</div><div>Копия: PostgreSQL mailing lists (<a href="mailto:pgsql-bugs@lists.postgresql.org" rel="noopener noreferrer">pgsql-bugs@lists.postgresql.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" &lt;<a href="mailto:x4mmm@yandex-team.ru" rel="noopener noreferrer">x4mmm@yandex-team.ru</a>&gt;:</div><blockquote><p><br /> </p><blockquote> On 16 Jun 2026, at 23:36, Álvaro Herrera &lt;<a href="mailto:alvherre@kurilemu.de" rel="noopener noreferrer">alvherre@kurilemu.de</a>&gt; wrote:<br /> <br /> On 2026-Jun-15, Andrey Borodin wrote:<br /> <blockquote><blockquote> On 15 Jun 2026, at 18:39, PG Bug reporting form &lt;<a href="mailto:noreply@postgresql.org" rel="noopener noreferrer">noreply@postgresql.org</a>&gt; 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&quot; rel="noopener noreferrer">https://postgr.es/c/e35e466f61b&lt;/a&gt;&lt;br /> [2] <a href="https://postgr.es/c/2bb60eb4fea&quot; rel="noopener noreferrer">https://postgr.es/c/2bb60eb4fea&lt;/a&gt;&lt;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>

On Wed, Jun 17, 2026 at 09:49:22PM +0500, Сергей Дм. Апойченко wrote:

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.

Okay, thanks for the update. The handling of multixacts during
recovery has already been tweaked a bit. I think that we are in a
good spot in terms of lock handling in the stable branches, but if you
still see something strange, please feel free to update this thread
with more information for investigation.
--
Michael