Christopher Browne wrote: > [EMAIL PROTECTED] (Hideyuki Kawashima) wrote: >> Joshua, >> >> I appreciate your quick & informative reply. And, I also really >> appreciate your kind comments. Since I have joined this ML 3 hours >> ago, I tried to be polite and slightly nervous. But I was relieved >> by your message. > > Your idea sounds interesting; there is likely to be a considerable > resistance to mechanisms, however, that would be likely to make > PostgreSQL less robust. > > Be aware, also, that in a public forum like this, people are sometimes > less gentle than Joshua. > > The fundamental trouble with this mechanism is that a power outage can > instantly turn a database into crud.
I can think of a few places where I don't care about the data if the power is lost - * Web-based session data A lot of web sites have separate session-only databases. If the database goes down, we have to truncate the tables anyways when it comes back up. * Reporting slaves We have replication slaves setup for internal (staff-only) reporting. Often a lot of temp and summary tables as well. If the data is lost, don't care. Its a reporting database. Re-syncing from another slave is no biggie for total data loss. Less a concern given the speed increase of the data it creates as well as data coming in from the master. * Front-end cache slaves Same type of situation as the reporting slaves. Basic front-end cache that replicates data to take load off the master. The slaves still have to do all the same insert/updates, but this means they'll spend less time in locks. They crash, point the apps to the master or another slave while you fix it. Weslee ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq