I've been reading with interest the comments about the transaction log management. First, I'm pretty new to PostgreSQL so please forgive any blatant errors or misunderstanding on my part. We want access to the log to be serialized and similarly we don't want fsync()s to happen in parallel nor do we want them to occur more than necessary. Hence the discussion that has been happening. It seems to me that, if any locking is to occur, it should be done using a semaphore mechanism of some kind (fcntl() locking will do) that is managed by the kernel. The reason is that as a DBA, I want to be able to kill off backend processes (with SIGKILL if necessary) without hanging the rest of the PostgreSQL system. Any setup where one backend process must actively signal the rest in order to wake them up is one that is vulnerable to this scenario. Much better to have them agree to attempt to acquire a lock on a file or a semaphore, in other words something managed by the system, so that when a process holding the lock dies the others can continue about their business. I realize that there are pitfalls with this approach: killing one of the backend processes can leave the database in an inconsistent state. But that seems a bit better than the alternative, which is that I'd have to kill ALL the backend processes, and have the database end up in the same state anyway. Thoughts? Guess it's time for me to subscriber to pgsql-hackers... :-) -- Kevin Brown [EMAIL PROTECTED] It's really hard to define what "anomalous behavior" means when you're talking about Windows.