current community

your communities

more stack exchange communities

company blog
Stack Exchange Inbox Reputation and Badges
tour help
Stack Overflow is a community of 4.7 million programmers, just like you, helping each other.

Join them; it only takes a minute:

Sign up
Join the Stack Overflow community to:
  1. Ask programming questions
  2. Answer and help your peers
  3. Get recognized for your expertise
up vote 2 down vote favorite

PostgreSQL supports asynchronous commits - that is, the database engine can be configured to report success even if the database has not completed the write ahead log sync.

http://www.postgresql.org/docs/8.3/static/runtime-config-wal.html#GUC-SYNCHRONOUS-COMMIT

This provides a useful compromise between running some queries in a manner that guarantees that in the event of database crash, it would remain in a consistent state, however, some allegedly committed transactions would appear as if they have been aborted cleanly.

Obviously for some transactions, it's critical that commits remain final - which is why the flag can be configured per transaction.

How can I take advantage of this functionality in django?

share|improve this question
1  
Looks like after starting your transaction, you'd call .raw('SET LOCAL synchronous_commit TO OFF;'); – Frank Farmer Oct 12 '12 at 23:14
    
That's quite useful - can it be configured to be run automatically on save of certain models? – qdot Oct 12 '12 at 23:17
up vote 2 down vote accepted

First I second Frank's note. That's the way to do it.

However if you do this you probably want to have a function which sets this on each API that may commit. This seems error prone to me so I probably wouldn't mess with it and would instead try hard to batch the transactions into the same transaction to the extent that makes sense. I would suggest further having a method in your models for showing the setting (SHOW synchronous_commit) so that you can properly unit test.

Again because this is a session setting this strikes me as a bit dangerous to play around with in this way, but it could be done if you take necessary precautions.

share|improve this answer
    
It's actually difficult to batch transactions that way - basically the system is a yet-another-log-analyzer solution, designed to catch huge streams of log data from deployed programs. Thus, the config tables and the analysis tables need strict ACID guarantees, but the actual log table, just needs clean restart - some entries would get lost in the event of a failure, let's allow more of them to be lost and get huge performance gains. Perhaps I'd just use two database connections instead, one for the safe models, one for the fast stream models? – qdot Oct 13 '12 at 14:55

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.