1. 21 1月, 2007 20 次提交
  2. 20 1月, 2007 13 次提交
  3. 18 1月, 2007 5 次提交
  4. 17 1月, 2007 2 次提交
    • B
      3026e176
    • T
      Revise bgwriter fsync-request mechanism to improve robustness when a table · 6d660587
      Tom Lane 提交于
      is deleted.  A backend about to unlink a file now sends a "revoke fsync"
      request to the bgwriter to make it clean out pending fsync requests.  There
      is still a race condition where the bgwriter may try to fsync after the unlink
      has happened, but we can resolve that by rechecking the fsync request queue
      to see if a revoke request arrived meanwhile.  This eliminates the former
      kluge of "just assuming" that an ENOENT failure is okay, and lets us handle
      the fact that on Windows it might be EACCES too without introducing any
      questionable assumptions.  After an idea of mine improved by Magnus.
      
      The HEAD patch doesn't apply cleanly to 8.2, but I'll see about a back-port
      later.  In the meantime this could do with some testing on Windows; I've been
      able to force it through the code path via ENOENT, but that doesn't prove that
      it actually fixes the Windows problem ...
      6d660587