| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Michael Harris <harmic(at)gmail(dot)com>, Tomas Vondra <tomas(at)vondra(dot)me>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: FileFallocate misbehaving on XFS |
| Date: | 2024-12-16 23:23:45 |
| Message-ID: | CA+TgmoZv7G57yRhHH4cdRPBnqkOrg6T-FZgExtwz263MpVRZHA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Dec 16, 2024 at 12:52 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> I don't see what we gain by requiring guesswork (what does allocating vs
> zeroing mean, zeroing also allocates disk space after all) to interpret the
> main error message. My experience is that it's often harder to get the DETAIL
> than the actual error message (grepping becomes harder due to separate line,
> terse verbosity is commonly used).
I feel like the normal way that we do this is basically:
could not {name of system call} file "\%s\": %m
e.g.
could not read file \"%s\": %m
I don't know why we should do anything else in this type of case.
--
Robert Haas
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jelte Fennema-Nio | 2024-12-16 23:26:20 | Re: Log connection establishment timings |
| Previous Message | Peter Smith | 2024-12-16 23:16:47 | Re: Question about behavior of deletes with REPLICA IDENTITY NOTHING |