From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Brian Hirt <bhirt(at)mobygames(dot)com> |
Cc: | Gaetano Mendola <mendola(at)bigfoot(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: will PITR in 8.0 be usable for "hot spare"/"log shipping" type |
Date: | 2004-08-12 02:40:09 |
Message-ID: | 23262.1092278409@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Brian Hirt <bhirt(at)mobygames(dot)com> writes:
> I wonder if there will be assumptions in the startup code concerning
> time. What if the startup takes 18 months, would there be some sort
> of problem with this approach you think?
I don't know of any such assumptions, but this sort of question is why
someone should prototype it while we're still in beta ...
One point that occurred to me is that you aren't really going to want to
just leave the slave sitting there updating an original backup forever.
Anytime the slave machine itself crashes (power outage, say) it will
have to replay the log again from the time of the original backup ---
so you have to keep all the copied log segments in place. I would guess
that you'll want to refresh the slave's starting backup about as often
as you take a new base backup for the master, and for about the same
reason: you want to limit how many archived WAL segments you have to
keep.
So in theory it should work, but there are a lot of procedural details
to be resolved to translate that handwavy sketch into a reliable
process --- and maybe we'll find that we need to adjust some details
of how the basic recovery process works in order to make the idea
really practical. So like I said, I'd love for somebody to prototype
it while we can still rejigger details.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-08-12 02:42:15 | Re: pg_restore (libpq? parser?) bug in 8 |
Previous Message | Philip Warner | 2004-08-12 02:28:08 | Re: pg_restore (libpq? parser?) bug in 8 |