On Sat, Jan 9, 2016 at 6:26 PM, Andres Freund <and...@anarazel.de> wrote: > > On 2016-01-09 18:24:01 +0530, Amit Kapila wrote: > > Okay, but I think that is the reason why you are worried that it is possible > > to issue sync_file_range() on a closed file, is that right or am I missing > > something? > > That's one potential issue. You can also fsync a different file, try to > print an error message containing an unallocated filename (that's how I > noticed the issue in the first place)... > > I don't think it's going to be acceptable to issue operations on more or > less random fds, even if that operation is hopefully harmless. >
Right that won't be acceptable, however I think with your latest proposal [1], we might not need to solve this problem or do we still need to address it. I think that idea will help to mitigate the problem of backend and bgwriter writes as well. In that, can't we do it with the help of existing infrastructure of *pendingOpsTable* and *CheckpointerShmem->requests[]*, as already the flush requests are remembered in those structures, we can use those to apply your idea to issue flush requests. [1] "It seems better to track a fixed number of outstanding 'block flushes', independent of the file. Whenever the number of outstanding blocks is exceeded, sort that list, and flush all outstanding flush requests after merging neighbouring flushes." With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
