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 >[email protected] >http://lists.gnu.org/mailman/listinfo/gnumed-devel _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
