From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | pgsql-committers(at)lists(dot)postgresql(dot)org |
Subject: | pgsql: fd.c: Retry after EINTR in more places |
Date: | 2023-06-19 21:12:06 |
Message-ID: | E1qBMAP-002c1n-F1@gemulon.postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
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(at)debian(dot)org>
Discussion: https://postgr.es/m/ZEZDj1H61ryrmY9o@msg.df7cb.de
Backpatch: -
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/0d369ac650041862ed5006885160f36d24b224a4
Modified Files
--------------
src/backend/storage/file/fd.c | 73 ++++++++++++++++++++++++++++++++++++-------
1 file changed, 61 insertions(+), 12 deletions(-)
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2023-06-19 22:58:55 | Re: pgsql: Fix search_path to a safe value during maintenance operations. |
Previous Message | Robert Haas | 2023-06-19 20:03:36 | Re: pgsql: Fix search_path to a safe value during maintenance operations. |