> It might be interesting to think about not requiring the ControlFileLock
> to be held while making new WAL segments. I think the only reason it
> does that is to ensure that link/rename failure can be treated as a hard
> error (because no one could have beat us to the filename), but we're
> already having to back off that stance for Windows ...
on a sidenote, i was able to work around the total xlog-lock by ingreasing
checkpoint_segments from 3 (default) to 12. that seems enough to have the
processes release (timeout?) the filehandles before writer-process wants to
rename the xlog file, at least under normal workload. if there is a data
load, the lockup still happens, but i can live with that for now.
the logs are still being swamped with the other delete error messages, tho:
2006-10-27 16:16:58 [5828] ERROR: XX000: storage sync failed on magnetic
disk: Permission denied
2006-10-27 16:16:58 [5828] LOCATION: smgrsync, smgr.c:888
2006-10-27 16:16:59 [5828] LOG: 42501: could not fsync segment 0 of
relation 1663/3964774/6495380: Permission denied
2006-10-27 16:16:59 [5828] LOCATION: mdsync, md.c:785
2006-10-27 16:16:59 [5828] ERROR: XX000: storage sync failed on magnetic
disk: Permission denied
2006-10-27 16:16:59 [5828] LOCATION: smgrsync, smgr.c:888
magnus, where you able to do a debug build for me to test the patch? would
be nice if a solution could be found for the final 8.2 release.
cheers,
thomas
