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

[Syan Tan]

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.
Another darn end-to-end problem. 
Snapshotting worked ok many years ago, for ordinary filesystem usage.
When I was doing a part time IT course, students used to be able to 
go to another part of the filesystem and look at several copies 
of their work of different ages , just in case they accidently
did rm -fr part or all of a current project. Some of the work , the last
few minutes, might be lost though. 

With respect to using timestamps end-to-end at the application level,
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 ;
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, and others trying to modify the same
section of the record, would need to be informed that the lock was being
held, and to try again later ( would only occur in concurrent modification,
not concurrent addition of items , as long as there was a way of marking
concurrent additions as being concurrent, and hence the entry made
only based on older information not marked concurrent  e.g. 
scenario , patient informed current tests normal, concurrent entry, abnormal
result, requires patient to be informed ).


On Mon Oct  8 11:54 , Karsten Hilbert  sent:

>On Mon, Oct 08, 2007 at 08:01:45AM +0000, Syan Tan wrote:
>
>> ZFS is apparently copy-on-write according to wikipedia , sounds
>> like multiversion timestamping concurrency control used at the operating 
>> system
>> filesystem level,
>> only ZFS sounds faster than postgres. 
>
>Oh, I was maybe mistaking ZFS for Btrfs which can do
>snapshots and thus freeze a particular "view" of the FS at a
>given point in time which would be needed for meaningful
>(read consistent) filesystem level backups w/o stopping the
>PostgreSQL server.
>
>Karsten
>-- 
>GPG key ID E4071346 @ wwwkeys.pgp.net
>E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346