Re: [Gnumed-devel] update database - no problem

[Karsten Hilbert]

On Tue, Oct 09, 2007 at 05:54:17AM +0000, Syan Tan wrote:

> It's feasible that ZFS might snapshot postgresql in the middle of a 
> transaction
> and the rest of the transaction is not included the snapshot.
Well, no, that's the whole point of WAL.

The transaction is first written the transaction log. If
that fails/is snapshotted midways - no problem. The
transaction is not marked complete and is thus considered
"not there" in the snapshot.

If it was marked complete in the WAL but has not yet made
its way to the table, IOW failure/snapshot between log-done
but table-not-done - no problem. The transaction will be
redone from WAL to table when the snapshotted state is
brought up.

This is standard log based system recovery, just like ext3.

> With respect to using timestamps end-to-end at the application level,
timestamps are tempting to misuse - to rely on consecutivity
where consecutivity may or may not really be needed

> it's fairly simple compared to running session transactions. 
> Other ways of doing things would be to hold entire record locks, which is
> the way our simple MD works, so only one person can open up the record ;
We don't want that.

> invoke section locks, so that as soon any entry is made into the record,
> that section needs to have a lock acquired before being modified, and the 
> lock released after being modified,
"Locks" are taken anyways - IOW our transactions are
serializable. No two concurrent transactions can modify the
same item two ways without one failing.

What we are protecting against with XMIN is
*cross-transaction* semantic overwrites.

But we are veering off: The thread started with consistent
backups w/o stopping the PG server.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346