On Fri, 3 Jul 2026 at 05:54, Xuneng Zhou <[email protected]> wrote:
> > On Wed, 6 May 2026 at 14:24, Feike Steenbergen < [email protected]> wrote: > > > For now, the problem disappears again when switching to io_method='worker' > > > > I spoke too soon it seems. It happens less frequently, but we do still have the issue even with io_method='worker'. > > Reverting to io_method='sync' as I would expect that will solve the issue. > > Interestingly, I wonder why this variance would occur in production. > This is the more interesting part of this thread. I did some > investigation & experiment, pg 19 passed the reproducer even if > da6874635db is removed. A series of improvements made in April may > contribute to this. Will return soon to share the findings.. Indeed, we see the problem occur at *all* settings of io_method. As it is slightly unpredictable, a retry of a transaction may succeed afterwards, so our production application is mostly fine. We did observe these errors right after upgrading to pg19, then we didn't observe the error for a full 3 weeks, but now we observe the error dozens of times every hour. Our application has a bit of a cadence though, it only does its work 5/6 hours, and the error is only showing when the application is actually doing work. > 2) Three engines, two pools > > To be continued... On our end, we're trying to reduce connections (batch more, queue work outside the db more), however, it would be great if this problem can be fully identified and resolved in pg itself. Kind regards, Feike
