On Fri, 2008-12-05 at 16:00 +0900, Fujii Masao wrote:
> On Fri, Dec 5, 2008 at 12:09 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
> >> I was expecting you to have walreceiver and startup share an end of WAL
> >> address via shared memory, so that startup never tries to read past end.
> >> That way we would be able to begin reading a WAL file *before* it was
> >> filled. Waiting until a file fills means we still have to have
> >> archive_timeout set to ensure we switch regularly.
> >
> > You mean that not pg_standby but startup process waits for the next
> > WAL available? If so, I agree with you in the future. That is, I just think
> > that this is next TODO because there are many problems which we
> > should resolve carefully to achieve it. But, if it's essential for 8.4, I will
> > tackle it. What is your opinion? I'd like to clear up the goal for 8.4.
>
> Umm.. on second thought, this feature (continuous recovery without
> pg_standby) seems to be essential for 8.4. So, I will try it.
Sounds good. Perhaps you can share what changed your mind in those 4
hours...
Could we start with pictures and some descriptions first, so we know
we're on the right track? I foresee no coding issues.
My understanding is that we start with a normal log shipping
architecture, then we switch into continuous recovery mode. So we do use
pg_standby at beginning, but then it gets turned off.
Let's look at all of the corner cases also:
* standby keeps pace with primary (desired state)
* standby falls behind primary
* standby restarts to change shmmem settings
etc
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
