Re: BUG #2712: could not fsync segment: Permission
От | Thomas H. |
---|---|
Тема | Re: BUG #2712: could not fsync segment: Permission |
Дата | |
Msg-id | 026d01c6f6e4$c1845750$0201a8c0@iwing обсуждение исходный текст |
Ответ на | BUG #2712: could not fsync segment: Permission denied ("Thomas H" <me@alternize.com>) |
Ответы |
Re: BUG #2712: could not fsync segment: Permission
|
Список | pgsql-bugs |
> 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
В списке pgsql-bugs по дате отправления: