aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor/execUtils.c
diff options
context:
space:
mode:
authorAndres Freund <andres@anarazel.de>2023-06-19 14:11:32 -0700
committerAndres Freund <andres@anarazel.de>2023-06-19 14:11:32 -0700
commit0d369ac650041862ed5006885160f36d24b224a4 (patch)
tree248307f08755a27a4ac37211018b98e5ed55bd13 /src/backend/executor/execUtils.c
parent797f98036400bc70d4b331c5b1760a05aab59cfa (diff)
downloadpostgresql-0d369ac650041862ed5006885160f36d24b224a4.tar.gz
postgresql-0d369ac650041862ed5006885160f36d24b224a4.zip
fd.c: Retry after EINTR in more places
Starting with 4d330a61bb1 we can use posix_fallocate() to extend files. Unfortunately in some situation, e.g. on tmpfs filesystems, EINTR may be returned. See also 4518c798b2b. To fix, add a retry path to FileFallocate(). In contrast to 4518c798b2b the amount we extend by is limited and the extending may happen at a high frequency, so disabling signals does not appear to be the correct path here. Also add retry paths to other file operations currently lacking them (around fdatasync(), fsync(), ftruncate(), posix_fadvise(), sync_file_range(), truncate()) - they are all documented or have been observed to return EINTR. Even though most of these functions used in the back branches, it does not seem worth the risk to backpatch - outside of the new-to-16 case of posix_fallocate() I am not aware of problem reports due to the lack of retries. Reported-by: Christoph Berg <myon@debian.org> Discussion: https://postgr.es/m/ZEZDj1H61ryrmY9o@msg.df7cb.de Backpatch: -
Diffstat (limited to 'src/backend/executor/execUtils.c')
0 files changed, 0 insertions, 0 deletions