| From: | "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at> |
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Andreas Pflug" <pgadmin(at)pse-consulting(dot)de> |
| Cc: | <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: PITR Functional Design v2 for 7.5 |
| Date: | 2004-03-10 18:58:04 |
| Message-ID: | 46C15C39FEB2C44BA555E356FBCD6FA40184D016@m0114.s-mxs.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> > To clarify:
> > I'd expect a cluster to be workable, if I
> > - disable VACUUM until backup completed
> > - issue CHECKPOINT
> > - backup clog (CHECKPOINT and backup clog are the "backup checkpoint")
> > - backup all datafiles (which include at least all completed transaction
> > data at checkpoint time)
> > and then
> > - restore datafiles and clog
> > - bring up pgsql.
>
> Why is that a useful approach? You might as well shut down the
> postmaster and do a cold filesystem backup, because you are depending on
> the data files (including clog) not to change after the checkpoint. You
> cannot make such an assumption in a running database.
I think there is a misunderstanding here.
What I think is possible is the following (continuous backup of WAL assumed):
- disable VACUUM
- issue CHECKPOINT "C1"
- backup all files
- reenable VACUUM
- restore files
- adapt pg_control (checkpoint "C1")
- recover WAL until at least end of backup
The db is inconsistent until you recovered all WAL (PITR) that accumulated during
file backup.
I am not sure about clog, isn't clog logged in xlog ?
Andreas
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Marcelo Carvalho Fernandes | 2004-03-10 18:59:24 | PANIC on start |
| Previous Message | Thomas Swan | 2004-03-10 18:45:13 | Re: [GENERAL] Shouldn't B'1' = 1::bit be true? |