Recovering from crash

[Andrew Sullivan]

On Wed, Oct 12, 2011 at 01:00:49PM -0400, Derek Atkins wrote:
> 
> Because it's a "transaction log" and only logs transactions.  

Aha.  This is what you get for looking at everything through a SQL
lens.  I thought "transaction" was, of course, "something the program
did", but on reflection that was just clearly a misplaced expectation
on my part.

> to Accounts, either, so if you added or deleted or otherwise modified an
> account that change wont be recorded in the log.  

But if you performed a transaction that caused the account to be
increased or decreased, it would be logged?  (I guess I'm confused
here, because when you post an invoice it does alter an account, which
should be a transaction, no?  The docs seem to suggest that what you
actually get is maybe a transaction entry without the associated
invoices and so on.  This is a powerful incentive to move everything
onto Postgres soon.)

Anyway, I'm wrong that this isn't pointed out specifically in the
documentation.  It's in section 2.7.2 of the 2.2 concepts guide, so my
apologies for suggesting this isn't well-documented.  But the moral of
the story is obviously save early, and save often.

> "Log Replay" has always been somewhat of a hack as an interim stopgap to
> help users in some cases until we could fully migrate to SQL, which is
> the true answer for not losing any data.

Got it.

> If an application crashes you lose data.  Period.  That's true for
> pretty much any application.  Even if you have autosave turned on, there
> is still a window.  Show me any application that doesn't use a database
> that will *never* lose data.

Well, I can even show you applications that _do_ use a database that
lose data (pretty much anything depending on MySQL in non-InnoDB mode,
for instance), but I get the point.  I understood the transaction log
to be providing ACID itself, but clearly that's not what it's doing.
This was just my misapprehension.

A

-- 
Andrew Sullivan
ajs at anvilwalrusden.com