Skip to content
Snippets Groups Projects
Select Git revision
  • benchmark-tools
  • postgres-lambda
  • master default
  • REL9_4_25
  • REL9_5_20
  • REL9_6_16
  • REL_10_11
  • REL_11_6
  • REL_12_1
  • REL_12_0
  • REL_12_RC1
  • REL_12_BETA4
  • REL9_4_24
  • REL9_5_19
  • REL9_6_15
  • REL_10_10
  • REL_11_5
  • REL_12_BETA3
  • REL9_4_23
  • REL9_5_18
  • REL9_6_14
  • REL_10_9
  • REL_11_4
23 results

win32error.c

Blame
    • Magnus Hagander's avatar
      9951741b
      Attempt to handle pending-delete files on Windows · 9951741b
      Magnus Hagander authored
      These files are deleted but not yet gone from the filesystem. Operations
      on them will return ERROR_DELETE_PENDING.
      
      With this we start treating that as ENOENT, meaning files does not
      exist (which is the state it will soon reach). This should be safe in
      every case except when we try to recreate a file with exactly the same
      name. This is an operation that PostgreSQL does very seldom, so
      hopefully that won't happen much -- and even if it does, this treatment
      should be no worse than treating it as an unhandled error.
      
      We've been un able to reproduce the bug reliably, so pushing this to
      master to get buildfarm coverage and other testing. Once it's proven to
      be stable, it should be considered for backpatching.
      
      Discussion: https://postgr.es/m/20160712083220.1426.58667%40wrigleys.postgresql.org
      
      Patch by me and Michael Paquier
      9951741b
      History
      Attempt to handle pending-delete files on Windows
      Magnus Hagander authored
      These files are deleted but not yet gone from the filesystem. Operations
      on them will return ERROR_DELETE_PENDING.
      
      With this we start treating that as ENOENT, meaning files does not
      exist (which is the state it will soon reach). This should be safe in
      every case except when we try to recreate a file with exactly the same
      name. This is an operation that PostgreSQL does very seldom, so
      hopefully that won't happen much -- and even if it does, this treatment
      should be no worse than treating it as an unhandled error.
      
      We've been un able to reproduce the bug reliably, so pushing this to
      master to get buildfarm coverage and other testing. Once it's proven to
      be stable, it should be considered for backpatching.
      
      Discussion: https://postgr.es/m/20160712083220.1426.58667%40wrigleys.postgresql.org
      
      Patch by me and Michael Paquier