Re: FileFallocate misbehaving on XFS - Mailing list pgsql-hackers

From Robert Haas
Subject Re: FileFallocate misbehaving on XFS
Date
Msg-id CA+TgmoZMW2PW4_zc4Dn=-jYk94YuUrYxSX066xVAfYtkZZFoRA@mail.gmail.com
Whole thread Raw
In response to Re: FileFallocate misbehaving on XFS  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-hackers
On Sat, Dec 14, 2024 at 4:20 AM Thomas Munro <thomas.munro@gmail.com> wrote:
> On Sat, Dec 14, 2024 at 9:29 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> > On 2024-Dec-11, Andres Freund wrote:
> > > One thing that I think we should definitely do is to include more detail in
> > > the error message. mdzeroextend()'s error messages don't include how many
> > > blocks the relation was to be extended by. Neither mdextend() nor
> > > mdzeroextend() include the offset at which the extension failed.
> >
> > I proposed a patch at
> > https://postgr.es/m/202409110955.6njbwzm4ocus@alvherre.pgsql
>
> If adding more logging, I wonder why FileAccess()'s "re-open failed"
> case is not considered newsworthy.  I've suspected it as a candidate
> source of an unexplained and possibly misattributed error in other
> cases.  I'm not saying it's at all likely in this case, but it seems
> like just the sort of rare unexpected failure that we'd want to know
> more about when trying to solve mysteries.

Wow. That's truly abominable. It doesn't seem likely to explain this
case, because I don't think trying to reopen an existing file could
result in LruInsert() returning ENOSPC. But this code desperately
needs refactoring to properly report the open() failure as such,
instead of conflating it with a failure of whatever syscall we were
contemplating before we realized we needed to open().

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: torikoshia
Date:
Subject: Re: Enhancing Memory Context Statistics Reporting
Next
From: Thomas Munro
Date:
Subject: Re: Windows UTF8 system locale