The Linux OOM Killer heuristic can be summed up as:
- Run out of memory.
- Kill PostgreSQL.
- Look for processes that might be using too much memory, and kill them, hopefully freeing memory.
Notice that step #2 is independent of factors like:
- Is PostgreSQL consuming a significant share of the memory resources?
- Will killing PostgreSQL alleviate any memory pressure at all? Continue reading
In the last article, I argued that:
- A schedule conflict is a typical business problem.
- The later you try to resolve a schedule conflict, the more costly it is to resolve.
- In particular, there is a big jump in the cost the moment after conflicting data is recorded.
- Therefore, it’s best for the DBMS itself to enforce the constraint, because only the DBMS can avoid the conflict effectively before the conflict is recorded.
Then, I opened up a discussion to see how people are dealing with these schedule conflicts. In the comments I received at the end of the article, as well as other anecdotes from conferences, user groups, mailing lists, and my own experience, the solutions fall into a few categories:
“Schedule conflict” — it’s one of the simplest and most common constraints for business or any other organization. One person cannot be in two places at the same time; and in many cases a only a single person can use a given resource at any time.
Does your database system know anything about a schedule conflict? Should it?
Constraints are always enforced at some point, it’s just a matter of when, how, and the cost of correcting the situation.