Setting aside the appeal to authority and the outright condescension, POLA still can't be dispelled using a "nasal demons" argument. In practice the intentiona

Setting aside the appeal to authority and the outright condescension, POLA still can't be dispelled using a "nasal demons" argument. In practice the intentional vagueness is indistinguishable from obfuscation, and doing so to please every vendor for conformance's sake is straightforward intellectual dishonesty. In this regard, the informational section is tantamount to an extended reprimand from the editors. If you really want to trade language-lawyer broadsides, then leaning on the phrase "implementation-defined" was a tragic mistake, because this makes the Linux documentation normative for the circumstances, yet the behaviour occurring is not described in the Linux fsync(2) manpage, nor are there cross-references to anything FS-specific. It gets worse: the engineering solution to this schmozzle is switch to direct IO, but the documentation of Linux's open(2) then describes the behaviour of O_SYNC|O_DIRECT in terms of fsync(2) (and similarly for O_DSYNC). All this simply highlights that the whole line of thinking is an unproductive pissing contest; the root cause of the postgres issue is vendor politics.