> Actually, now that I look back in the archives, I think we had theorized
> that the fsync errors come from attempting to fsync a file that's
> already been deleted but some backend still has a reference to.
> Apparently that leads to EACCES instead of ENOENT (which the code is
> already prepared to expect).
with process explorer i can actually check which postgres.exe instance (in
all cases i've checked its just 1 instance, and always just 1 file) holds
the lock for the file in question. but will that help in determining why it
is still holding a reference?
the postgres instance that holds the lock eventually closes the filehandle
after some minutes. the process itself is not killed but continues
thereafter.
let me know if i can be of any assistance. since we do regurarly reindex one
table whose index size keeps growing despite of often vacuuming, the
fsync-problem happens almost 4-5 times per hour.
regards,
thomas