Peter Eisentraut <peter_e@gmx.net> writes:
> Matt writes:
>> If the theory can be robustly demonstrated to work in practice (which
>> you may have already done) then I say this strategy needs to be
>> recognised in the docs (or at least the techdocs) as a valid and useful one.
> The note in the documentation is rather old. If you can conclusively
> disprove it, then we'll be happy to alter it.
More to the point, the note is intended to discourage people from using
simple methods like tar or rsync duplication, which will most definitely
not work.
A snapshot implemented with help from something that sits between
Postgres and the disk theoretically could work. Being conservative
database weenies, we'd like to see some proof that it actually works
in practical cases before we endorse it ;-).
BTW: aside from the question of the integrity of the snapshot backup,
I'd be inclined to ask hard questions about the effects on database
performance from using the disk-freezing feature in the first place.
What is the LVM layer doing with the writes that occur while the
frozen snapshot is maintained?? If they're not getting to disk at
all, then "commits" that occur during the freeze aren't really commits
(and one can be pardoned for wondering whether write ordering
constraints will be honored when the floodgate is reopened). If they
are getting to disk, this seems to imply data journaling is being used,
which is probably a net loss for overall database performance. You
might be willing to pay that cost to be able to use this backup
technique --- but you should find out what that cost is ...
regards, tom lane
