Re: fsync and semctl errors with 8.1.5/win32
От | Tom Lane |
---|---|
Тема | Re: fsync and semctl errors with 8.1.5/win32 |
Дата | |
Msg-id | 6739.1164750349@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: fsync and semctl errors with 8.1.5/win32 ("Jeremy Haile" <jhaile@fastmail.fm>) |
Список | pgsql-bugs |
"Jeremy Haile" <jhaile@fastmail.fm> writes: > Here's a few seconds of the log output (this has been going on for 10 > mins as of this e-mail being sent): > 2006-11-28 16:16:10 LOG: could not fsync segment 0 of relation > 1663/16404/30267: Permission denied > 2006-11-28 16:16:10 ERROR: storage sync failed on magnetic disk: > Permission denied > Here's the FileMon output from the same seconds: > 4:16:10 PM postgres.exe:3168 OPEN C:\Program > Files\PostgreSQL\8.1\data\base\16404\30267 DELETE PEND Options: > Open Access: 0012019F I still don't want to make mdsync() treat EACCES as an ignorable error. However, in this situation we've got an infinite loop because the checkpoint will never succeed and thus the bgwriter will never reach smgrcloseall(), which seems to be what's needed to allow the deleted file to die the real death. Perhaps a suitable workaround would be to make the bgwriter do smgrcloseall in its error recovery path? That is /* * Sleep at least 1 second after any error. A write error is likely * to be repeated, and we don't want to be filling the error logs as * fast as we can. */ pg_usleep(1000000L); + + /* Drop open files to allow deleted files to really go away */ + smgrcloseall(); } /* We can now handle ereport(ERROR) */ PG_exception_stack = &local_sigjmp_buf; Perhaps this should be #ifdef WIN32, although there's probably no harm in doing it on Unixen too. Can someone test this idea? regards, tom lane
В списке pgsql-bugs по дате отправления: