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 kevin@sysexperts.com
It's really hard to define what "anomalous behavior" means when you're talking about Windows.
