]> granicus.if.org Git - postgresql/commit
Per previous discussions, get rid of use of sync(2) in favor of
authorTom Lane <tgl@sss.pgh.pa.us>
Mon, 31 May 2004 03:48:10 +0000 (03:48 +0000)
committerTom Lane <tgl@sss.pgh.pa.us>
Mon, 31 May 2004 03:48:10 +0000 (03:48 +0000)
commit9b178555fc1f5087c120ff4d26380395bc655a03
tree3578c76707795c2b25910ea42b36928eb6d4d742
parentf024086db30f26905e4c877a6795c1ab95f4ab12
Per previous discussions, get rid of use of sync(2) in favor of
explicitly fsync'ing every (non-temp) file we have written since the
last checkpoint.  In the vast majority of cases, the burden of the
fsyncs should fall on the bgwriter process not on backends.  (To this
end, we assume that an fsync issued by the bgwriter will force out
blocks written to the same file by other processes using other file
descriptors.  Anyone have a problem with that?)  This makes the world
safe for WIN32, which ain't even got sync(2), and really makes the world
safe for Unixen as well, because sync(2) never had the semantics we need:
it offers no way to wait for the requested I/O to finish.

Along the way, fix a bug I recently introduced in xlog recovery:
file truncation replay failed to clear bufmgr buffers for the dropped
blocks, which could result in 'PANIC:  heap_delete_redo: no block'
later on in xlog replay.
13 files changed:
src/backend/access/transam/clog.c
src/backend/access/transam/slru.c
src/backend/postmaster/bgwriter.c
src/backend/storage/buffer/bufmgr.c
src/backend/storage/file/fd.c
src/backend/storage/smgr/md.c
src/backend/storage/smgr/smgr.c
src/include/access/slru.h
src/include/postmaster/bgwriter.h
src/include/storage/bufmgr.h
src/include/storage/fd.h
src/include/storage/lwlock.h
src/include/storage/smgr.h