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

[Syan Tan]

There was a post about trying to justify using xmin, 
which was something like "it isn't pretty enough".
Actually, isn't having data cached at clients in database
objects like having a replicated database when two or more
clients have opened the same medical record. So if one
could make it look pretty by implementing two-phase commit
protocol amongst all the clients as well as the server.


On Tue Oct  9 10:34 , Karsten Hilbert   sent:

>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
>
>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
>
>
>_______________________________________________
>Gnumed-devel mailing list
>address@hidden
>http://lists.gnu.org/mailman/listinfo/gnumed-devel