"Jeremy Haile" <[EMAIL PROTECTED]> 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

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not
       match

Reply via email to