Обсуждение: pgsql: Remove special cases for ETXTBSY from new fsync'ing logic.
Remove special cases for ETXTBSY from new fsync'ing logic. The argument that this is a sufficiently-expected case to be silently ignored seems pretty thin. Andres had brought it up back when we were still considering that most fsync failures should be hard errors, and it probably would be legit not to fail hard for ETXTBSY --- but the same is true for EROFS and other cases, which is why we gave up on hard failures. ETXTBSY is surely not a normal case, so logging the failure seems fine from here. Branch ------ REL9_2_STABLE Details ------- http://git.postgresql.org/pg/commitdiff/77642a8197ed7fa3a5113bdca914e4685e957455 Modified Files -------------- src/backend/storage/file/fd.c | 15 +++------------ 1 file changed, 3 insertions(+), 12 deletions(-)
On 2015-05-29 19:11:58 +0000, Tom Lane wrote: > Andres had brought it up back when we were > still considering that most fsync failures should be hard errors, and it > probably would be legit not to fail hard for ETXTBSY --- but the same is > true for EROFS and other cases, which is why we gave up on hard failures. > ETXTBSY is surely not a normal case, so logging the failure seems fine > from here. Note that EROFS etc should never happen without following symlinks, whereas ETXTBSY conceivably could. I'm fine though, with the special case being removed, I think you made a good point that it's unlikely that e.g. an archive_command will run during startup.