Tom Lane 9b178555fc 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.		2004-05-31 03:48:10 +00:00
..
buffer	Per previous discussions, get rid of use of sync(2) in favor of	2004-05-31 03:48:10 +00:00
file	Per previous discussions, get rid of use of sync(2) in favor of	2004-05-31 03:48:10 +00:00
freespace	Ensure that close() and fclose() are checked for errors, at least in	2004-01-26 22:35:32 +00:00
ipc	Implement new PostmasterIsAlive() check for WIN32, per Claudio Natoli.	2004-05-30 03:50:15 +00:00
large_object	$Header: -> $PostgreSQL Changes ...	2003-11-29 19:52:15 +00:00
lmgr	Separate out bgwriter code into a logically separate module, rather	2004-05-29 22:48:23 +00:00
page	$Header: -> $PostgreSQL Changes ...	2003-11-29 19:52:15 +00:00
smgr	Per previous discussions, get rid of use of sync(2) in favor of	2004-05-31 03:48:10 +00:00
Makefile	$Header: -> $PostgreSQL Changes ...	2003-11-29 19:52:15 +00:00