First-draft release notes for back branches are up
On Sat, May 4, 2019 at 10:29 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Please send any corrections by Sunday.
+ Tolerate <literal>EINVAL</literal> and <literal>ENOSYS</literal>
+ error results, where appropriate, for fsync calls (Thomas Munro,
+ James Sewell)Nit-picking: ENOSYS is for sync_file_range, EINVAL is for fsync.
--
Thomas Munro
https://enterprisedb.com
Thomas Munro <thomas.munro@gmail.com> writes:
On Sat, May 4, 2019 at 10:29 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: + Tolerate <literal>EINVAL</literal> and <literal>ENOSYS</literal> + error results, where appropriate, for fsync calls (Thomas Munro, + James Sewell)
Nit-picking: ENOSYS is for sync_file_range, EINVAL is for fsync.
Yeah, I didn't really think it was worth distinguishing. If there
is some more general term that covers both calls, maybe we should
use that?
regards, tom lane
On Sat, May 4, 2019 at 1:29 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Thomas Munro <thomas.munro@gmail.com> writes:
On Sat, May 4, 2019 at 10:29 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: + Tolerate <literal>EINVAL</literal> and <literal>ENOSYS</literal> + error results, where appropriate, for fsync calls (Thomas Munro, + James Sewell)Nit-picking: ENOSYS is for sync_file_range, EINVAL is for fsync.
Yeah, I didn't really think it was worth distinguishing. If there
is some more general term that covers both calls, maybe we should
use that?
I would just do s/fsync/fsync and sync_file_range/. And I guess also
wrap them in <function>?
--
Thomas Munro
https://enterprisedb.com
On Fri, May 03, 2019 at 06:29:35PM -0400, Tom Lane wrote:
Please send any corrections by Sunday.
I have noticed a typo:
--- a/doc/src/sgml/release-11.sgml
+++ b/doc/src/sgml/release-11.sgml
@@ -982,7 +982,7 @@ Branch: REL9_4_STABLE [81f5b3283] 2019-03-04
09:50:24 +0900
<para>
Errors, such as lack of permissions to read the directory, were not
detected or reported correctly; instead the code silently acted as
- though the directory were empty.
+ though the directory was empty.
</para>
--
Michael
"Michael" == Michael Paquier <michael@paquier.xyz> writes:
Michael> I have noticed a typo:
Michael> Errors, such as lack of permissions to read the directory, were not
Michael> detected or reported correctly; instead the code silently acted as
Michael> - though the directory were empty.
Michael> + though the directory was empty.
"as though ... were ..." is correct English; it's a counterfactual
clause so the subjunctive is appropriate here.
--
Andrew (irc:RhodiumToad)
Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
"Michael" == Michael Paquier <michael@paquier.xyz> writes:
Michael> I have noticed a typo:
Michael> Errors, such as lack of permissions to read the directory, were not
Michael> detected or reported correctly; instead the code silently acted as
Michael> - though the directory were empty.
Michael> + though the directory was empty.
"as though ... were ..." is correct English; it's a counterfactual
clause so the subjunctive is appropriate here.
Thanks. It's been too long since high school English, so I was having
a hard time remembering the correct grammatical term for this; but
I'd just automatically written it that way and was pretty sure it
was right.
regards, tom lane
Thomas Munro <thomas.munro@gmail.com> writes:
On Sat, May 4, 2019 at 1:29 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Yeah, I didn't really think it was worth distinguishing. If there
is some more general term that covers both calls, maybe we should
use that?
I would just do s/fsync/fsync and sync_file_range/. And I guess also
wrap them in <function>?
OK, will do it like that.
regards, tom lane
On 5/3/19 6:29 PM, Tom Lane wrote:
See
Please send any corrections by Sunday.
Attached is a draft of the press release to go out. Please let me know
if there are any inaccuracies / glaring omissions / awkward language etc.
Thanks,
Jonathan
Attachments:
On Sun, May 5, 2019 at 2:35 PM Jonathan S. Katz <jkatz@postgresql.org> wrote:
On 5/3/19 6:29 PM, Tom Lane wrote:
See
Please send any corrections by Sunday.
Attached is a draft of the press release to go out. Please let me know
if there are any inaccuracies / glaring omissions / awkward language etc.
Hi Jonathan,
* Relax panics on fsync failures for certain cases where a failure indicated "operation not supported"
Maybe "fsync and sync_file_range". I suspect the latter actually
affected more people, but either way I think we should mention both.
* Fix handling of lc\_time settings that imply an encoding different from the database's encoding
Maybe this should be marked up as `lc_time` like other
identifier/file/whatever names?
* Several fixes for `conritb/postgres_fdw`, including one for remote partitions where an UPDATE could lead to incorrect results or a crash
Typo: contrib
--
Thomas Munro
https://enterprisedb.com
On 5/5/19 12:24 AM, Thomas Munro wrote:
On Sun, May 5, 2019 at 2:35 PM Jonathan S. Katz <jkatz@postgresql.org> wrote:
On 5/3/19 6:29 PM, Tom Lane wrote:
See
Please send any corrections by Sunday.
Attached is a draft of the press release to go out. Please let me know
if there are any inaccuracies / glaring omissions / awkward language etc.Hi Jonathan,
* Relax panics on fsync failures for certain cases where a failure indicated "operation not supported"
Maybe "fsync and sync_file_range". I suspect the latter actually
affected more people, but either way I think we should mention both.* Fix handling of lc\_time settings that imply an encoding different from the database's encoding
Maybe this should be marked up as `lc_time` like other
identifier/file/whatever names?* Several fixes for `conritb/postgres_fdw`, including one for remote partitions where an UPDATE could lead to incorrect results or a crash
Typo: contrib
Thanks! I have made all of those changes.
Best,
Jonathan