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

dbcommands.c

Blame
    • Heikki Linnakangas's avatar
      9cb91f90
      Fix two race conditions between the pending unlink mechanism that was put in · 9cb91f90
      Heikki Linnakangas authored
      place to prevent reusing relation OIDs before next checkpoint, and DROP
      DATABASE. First, if a database was dropped, bgwriter would still try to unlink
      the files that the rmtree() call by the DROP DATABASE command has already
      deleted, or is just about to delete. Second, if a database is dropped, and
      another database is created with the same OID, bgwriter would in the worst
      case delete a relation in the new database that happened to get the same OID
      as a dropped relation in the old database.
      
      To fix these race conditions:
      - make rmtree() ignore ENOENT errors. This fixes the 1st race condition.
      - make ForgetDatabaseFsyncRequests forget unlink requests as well.
      - force checkpoint on in dropdb on all platforms
      
      Since ForgetDatabaseFsyncRequests() is asynchronous, the 2nd change isn't
      enough on its own to fix the problem of dropping and creating a database with
      same OID, but forcing a checkpoint on DROP DATABASE makes it sufficient.
      
      Per Tom Lane's bug report and proposal. Backpatch to 8.3.
      9cb91f90
      History
      Fix two race conditions between the pending unlink mechanism that was put in
      Heikki Linnakangas authored
      place to prevent reusing relation OIDs before next checkpoint, and DROP
      DATABASE. First, if a database was dropped, bgwriter would still try to unlink
      the files that the rmtree() call by the DROP DATABASE command has already
      deleted, or is just about to delete. Second, if a database is dropped, and
      another database is created with the same OID, bgwriter would in the worst
      case delete a relation in the new database that happened to get the same OID
      as a dropped relation in the old database.
      
      To fix these race conditions:
      - make rmtree() ignore ENOENT errors. This fixes the 1st race condition.
      - make ForgetDatabaseFsyncRequests forget unlink requests as well.
      - force checkpoint on in dropdb on all platforms
      
      Since ForgetDatabaseFsyncRequests() is asynchronous, the 2nd change isn't
      enough on its own to fix the problem of dropping and creating a database with
      same OID, but forcing a checkpoint on DROP DATABASE makes it sufficient.
      
      Per Tom Lane's bug report and proposal. Backpatch to 8.3.