Ok. Let me try to make a resume of this, until somebody can chime and correct me...
1) Based on this
https://wiki.postgresql.org/wiki/Fsync_Errors
and this
https://lwn.net/Articles/752105/
particularly this justification:
"...Next, the reason why fsync() has the behaviour that it does is one
ofhe the most common cases of I/O storage errors in buffered use
cases, certainly as seen by the community distros, is the user who
pulls out USB stick while it is in use. In that case, if there are
dirtied pages in the page cache, the question is what can you do?
Sooner or later the writes will time out, and if you leave the pages
dirty, then it effectively becomes a permanent memory leak. You can't
unmount the file system --- that requires writing out all of the pages
such that the dirty bit is turned off. And if you don't clear the
dirty bit on an I/O error, then they can never be cleaned. You can't
even re-insert the USB stick; the re-inserted USB stick will get a new
block device. Worse, when the USB stick was pulled, it will have
suffered a power drop, and see above about what could happen after a
power drop for non-power fail certified flash devices --- it goes
double for the cheap sh*t USB sticks found in the checkout aisle of
Micro Center.
So this is the explanation for why Linux handles I/O errors by
clearing the dirty bit after reporting the error up to user space.
And why there is not eagerness to solve the problem simply by "don't
clear the dirty bit". For every one Postgres installation that might
have a better recover after an I/O error, there's probably a thousand
clueless Fedora and Ubuntu users who will have a much worse user
experience after a USB stick pull happens.
I can think of things that could be done --- for example, it could be
switchable on a per-block device basis (or maybe a per-mount basis)
whether or not the dirty bit gets cleared after the error is reported
to userspace. And perhaps there could be a new unmount flag that
causes all dirty pages to be wiped out, which could be used to recover
after a permanent loss of the block device. But the question is who
is going to invest the time to make these changes? If there is a
company who is willing to pay to comission this work, it's almost
certainly soluble..."
and this part of the paragraph:
"...But again, of the companies who have client code where we
care about robustness and proper handling of failed disk drives, and
which have a kernel team on staff, pretty much all of the ones I can
think of (e.g., Oracle, Google, etc.) use O_DIRECT and they don't try
to make buffered writes and error reporting via fsync(2) work well..."
I conclude that:
1) Fixing fsync() would cause other issues and might be technically challenging,
and some within Linux community dont have it as their highest priority
2) The onus falls mostly mostly on Postgres team, to re-implement their code
so as to use the "better" technical solution, as implemented for Linux
for similar scenarios by Oracle, Google and others...