| From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
|---|---|
| To: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com> |
| Cc: | "Toru SHIMOGAKI" <shimogaki(dot)toru(at)oss(dot)ntt(dot)co(dot)jp>, "Steve Atkins" <steve(at)blighty(dot)com>, "PostgreSQL Performance" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: PITR Backups |
| Date: | 2007-06-22 15:31:42 |
| Message-ID: | 87645gngyp.fsf@oxford.xeocode.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
>> So, if any data is written during taking snapshot, we can't assurance data
>> correctness *strictly* .
That sounds nothing like what I've heard called a "snapshot" before. Some
"filesystems" which aren't really filesystems but are also storage layer
drivers like Veritas (and ZFS?) allow you to take a snapshot which they
guarantee is atomic. You can do them while you have concurrent i/o and be sure
to get a single consistent view of the filesystem.
If you're just copying blocks from a device without any atomic snapshot
guarantee then you're going to get garbage. Even in Postgres wasn't writing
anything the OS might still choose to flush blocks during that time, possibly
not even Postgres data blocks but filesystem meta-information blocks.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dimitri | 2007-06-22 16:04:18 | Re: Data transfer very slow when connected via DSL |
| Previous Message | Rainer Bauer | 2007-06-22 14:38:06 | Re: Data transfer very slow when connected via DSL |