No, since most OS had (and still have) the "incorrect" behaviour. This was (and still is!) a generalised issue of fsync itself, since the state of buffers is undefined in case of failure.
The assumption that you could retry fsync on error was always effectively incorrect, per the posgres wiki on the subject openbsd, netbsd, and macos had essentially the same behaviour (invalidate buffers on failure). FreeBSD diverged from the rest because they rewrote brelse() long after separating from the others.
After this issue surfaced, openbsd updated their implementation to ensure the call would always fail, but only if the file is kept open which had not been guaranteed for postgres (don't know if it now is).
Linux had (has?) the additional issue of wonky error reporting, but that would not save your ass.
No, since most OS had (and still have) the "incorrect" behaviour. This was (and still is!) a generalised issue of fsync itself, since the state of buffers is undefined in case of failure.
The assumption that you could retry fsync on error was always effectively incorrect, per the posgres wiki on the subject openbsd, netbsd, and macos had essentially the same behaviour (invalidate buffers on failure). FreeBSD diverged from the rest because they rewrote brelse() long after separating from the others.
After this issue surfaced, openbsd updated their implementation to ensure the call would always fail, but only if the file is kept open which had not been guaranteed for postgres (don't know if it now is).
Linux had (has?) the additional issue of wonky error reporting, but that would not save your ass.