| From: | Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at> | 
|---|---|
| To: | "'Philip Warner'" <pjw(at)rhyme(dot)com(dot)au>, "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org> | 
| Subject: | AW: physical backup of PostgreSQL | 
| Date: | 2000-06-26 14:51:32 | 
| Message-ID: | 219F68D65015D011A8E000006F8590C605BA5995@sdexcsrv1.f000.d0188.sd.spardat.at | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
> At 12:13 26/06/00 +0200, Zeugswetter Andreas SB wrote:
> >After further thought I do think that a physical restore of a backup 
> >done with e.g. tar and pg_log as first file of backup does 
> indeed work.
> 
> Even if the file backup occurs in the middle of a vacuum?
I guess not, since at vacuum time the rows are moved inside the pages,
but that does not seem like a real world limitation to me.
> I like the idea of a non-SQL-based backup method, but it 
> would be nice to
> see some kind of locking being done to ensure that the backup 
> is a valid
> database snapshot. Can some kind of consistent page dump be 
> done? (Rather
> than a file copy)
Yes, it is the current smgr that makes any locking obsolete.
> I believe Vadim's future plans involve reuse of data pages - 
> would this
> have an impact on backup integrity?
Yes.
> My experience with applying journals to restored databases 
> suggests that
> the journals need to be applied to a 'known' state of the database -
> usually a snapshot as of a certain TX Seq No.
Yes, if Vadim changes things to overwrite. 
Of course we could have a db mode where nothing is overwritten,
since we have the code for that.
Andreas
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2000-06-26 14:55:33 | Re: Makefile for parser | 
| Previous Message | Tom Lane | 2000-06-26 14:42:31 | Re: File versioning (was: Big 7.1 open items) |