| From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "Koichi Suzuki" <suzuki(dot)koichi(at)oss(dot)ntt(dot)co(dot)jp>, "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "Toru SHIMOGAKI" <shimogaki(dot)toru(at)oss(dot)ntt(dot)co(dot)jp>, "Dan Gorman" <dgorman(at)hi5(dot)com>, <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: PITR Backups |
| Date: | 2007-06-25 15:00:25 |
| Message-ID: | 87fy4guliu.fsf@oxford.xeocode.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> AFAIK, actually workable methods of this type depend on filesystem
> cooperation, and are able to produce coherent snapshots of the logical
> (not necessarily physical) filesystem content at a specific instant.
I think you need filesystem cooperation in order to provide access to the
snapshot somewhere. But the actual snapshotting is done at a very low level by
intercepting any block writes and stashing away the old version before writing
or alternately by noting the new version and redirecting any reads to the new
version.
I concur that anything that doesn't allow concurrent i/o while the
snapshotting is happening is worthless. It sounds like you're just dd'ing from
the device which is pretty much guaranteed not to work.
Even if Postgres didn't do any i/o there's nothing stopping the OS and
filesystem from issuing i/o.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dan Gorman | 2007-06-25 15:26:52 | Re: PITR Backups |
| Previous Message | Tom Lane | 2007-06-25 14:31:49 | Re: PITR Backups |