Re: Database versus filesystem for storing images

> what happens if you rollback a transaction that just updated
> an image file?
>
> for that matter, what happens if one transaction is using or
> even reading an image while another is updating it?

One thing I mentioned was about a point in time backup, not updating the image.
This would rollback the transaction on the backup server, not the live one.

I was also proposing to never update an image. Just generate a new file, you
got 64-bits worth of ids. If you need to rollback an update to image on the
live server, unlink() the file and rollback. If all is good, unlink the old
version.

andrew

Ragnar wrote:
> On fös, 2007-01-05 at 15:49 -0500, Andrew Chernow wrote:
>> I 100% agree. Use the database as a lookup into the filesystem. Don't load the
>> database up with terabytes of non-searchable binary data? not sure how that
>> would help you?
>>
>
>> >I mean, how do you handle integrity with data
>> > outside the database?
>> You don't, the file system handles integrity of the stored data. Although, one
>> must careful to avoid db and fs orphans. Meaning, a record with no
>> corresponding file or a file with no corresponging record. Always
>> write()/insert an image file to the system within a transaction, including
>> writing the image out to the fs. Make sure to unlink any paritally written
>> image files.
>
> what happens if you rollback a transaction that just updated
> an image file?
>
> for that matter, what happens if one transaction is using or
> even reading an image while another is updating it?
>
> gnari
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>
>