Re: BufFileRead() error signalling
Alvaro Herrera <alvherre@2ndquadrant.com>
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Robert Haas <robertmhaas@gmail.com>, Thomas Munro <thomas.munro@gmail.com>, Ibrar Ahmed <ibrar.ahmad@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-05-27T15:59:59Z
Lists: pgsql-hackers
On 2020-Jan-29, Michael Paquier wrote: > On Tue, Jan 28, 2020 at 03:51:54PM -0500, Robert Haas wrote: > > I quickly reread that thread and I don't see that there's any firm > > consensus there in favor of "read %d of %zu" over "read only %d of %zu > > bytes". Now, if most people prefer the former, so be it, but I don't > > think that's clear from that thread. > > The argument of consistency falls in favor of the former on HEAD: > $ git grep "could not read" | grep "read %d of %zu" | wc -l > 59 > $ git grep "could not read" | grep "read only %d of %zu" | wc -l > 0 In the discussion that led to 811b6e36a9e2 I did suggest to use "read only M of N" instead, but there wasn't enough discussion on that fine point so we settled on what you now call prevalent without a lot of support specifically on that. I guess it was enough of an improvement over what was there. But like Robert, I too prefer the wording that includes "only" and "bytes" over the wording that doesn't. I'll let it be known that from a translator's point of view, it's a ten-seconds job to update a fuzzy string from not including "only" and "bytes" to one that does. So let's not make that an argument for not changing. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Commits
-
Make BufFileWrite() void.
- f5d18862bbb3 14.0 landed
-
Fix buffile.c error handling.
- 89020a92fb62 9.5.23 landed
- 02b71f06be75 9.6.19 landed
- 95647a1c7d29 10.14 landed
- 9c14d6024365 11.9 landed
- 28ee12669944 12.4 landed
- 3e0b08c404b2 13.0 landed
- 7897e3bb902c 14.0 landed
-
Adjust WAL code so that checkpoints truncate the xlog at the previous
- 1173344e74f7 7.2.1 cited