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

From Andres Freund
Subject Re: FileFallocate misbehaving on XFS
Date
Msg-id ztiev3chsnzv2inhti5cqtwiyu5uadxv3mgp4uqs7g3fvph4nd@kby5hk2wc3r7
Whole thread Raw
In response to Re: FileFallocate misbehaving on XFS  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: FileFallocate misbehaving on XFS
List pgsql-hackers
Hi,

On 2024-12-14 09:29:12 +0100, Alvaro Herrera 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
> 
> FileFallocate failure:
>         errmsg("could not allocate additional %lld bytes from position %lld in file \"%s\": %m",
>                (long long) addbytes, (long long) seekpos,
>                FilePathName(v->mdfd_vfd)),
> 
> FileZero failure:
>         errmsg("could not zero additional %lld bytes from position %lld file \"%s\": %m",
>                (long long) addbytes, (long long) seekpos,
>                FilePathName(v->mdfd_vfd)),

Personally I don't like the obfuscation of "allocate" and "zero" vs just
naming the function names. But I guess that's just taste thing.


> I'm not sure that we need to talk about blocks, given that the
> underlying syscalls don't work in blocks anyway.  IMO we should just
> report bytes.

When looking for problems it's considerably more work with bytes, because - at
least for me - the large number is hard to compare quickly and to know how
aggressively we extended also requires to translate to blocks.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: "Daniel Verite"
Date:
Subject: Re: UUID v7
Next
From: Andrew Dunstan
Date:
Subject: Re: Regression tests fail on OpenBSD due to low semmns value