On Thu, Feb 5, 2026 at 7:59 AM Andres Freund <andres@anarazel.de> wrote:
>
> Hi,
>
> On 2024-12-20 11:39:42 -0500, Andres Freund wrote:
> > On 2024-12-19 17:47:13 +1100, Michael Harris wrote:
> > > This is a different system to those I previously provided logs from.
> > > It is also running RHEL8 with a similar configuration to the other
> > > system.
> >
> > Given it's a RHEL system, have you raised this as an issue with RH? They
> > probably have somebody with actual XFS hacking experience on staff.
> >
> > RH's kernels are *heavily* patched, so it's possible the issue is actually RH
> > specific.
>
> FWIW, I raised this on the #xfs irc channel. One ask they had was:
>
> │15:56:40 dchinner | andres: can you get a metadump of a filesystem that is displaying these symptoms for us to
analyse?
> │15:57:54 dchinner | metadumps don't contain data, and metadata is obfuscated so no filenames or attributes are
exposed,either.
FWIW, I just learned yesterday that we went full circle on this:
Redhat has published [1] "XFS fallocate(2) returning ENOSPC
prematurely" several months ago. It references "commit
6773da870ab89123d1b513da63ed59e32a29cb77" titled "xfs: fix error
returns from xfs_bmapi_write" , so folks just need to update to proper
kernels. In addition we can do now:
postgresql_discovering_linux_kernel_bugs++. Quick search also shows
that e.g. linux-stable 6.1.x got it in 6.1.138 around May 2025, so
probably all kernels released before are all affected.
This pretty much matches the observation made earlier that it was
mainly hit by people upgrading databases on the same host without
updating OS/reinstalling hardware (re-using the older kernel).
BTW: from our side we also have workaround patch (with GUC for this)
solving 2nd problem and that is pending for inclusion in separate
thread[2]
-J.
[1] - https://access.redhat.com/solutions/7129010
[2] -
https://www.postgresql.org/message-id/flat/CAKZiRmyDR5d7jdKdhL6TNKMtcY0fAaS-OQ3Bk3ZVejLZMrTCQw%40mail.gmail.com#585ff2a71909c06a3c0d054d4f5a2383
by Thomas.
