From: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Streaming replication, retrying from archive |
Date: | 2010-01-14 19:36:07 |
Message-ID: | m2ska8zdg8.fsf@hi-media.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Fujii Masao <masao(dot)fujii(at)gmail(dot)com> writes:
> On Fri, Jan 15, 2010 at 1:06 AM, Dimitri Fontaine <dfontaine(at)hi-media(dot)com> wrote:
>> 0. base: slave asks the master for a base-backup, at the end of this it
>> reaches the base-lsn
>
> What if the WAL file including the archive recovery starting location has
> been removed from the primary's pg_xlog before the end of online-backup
> (i.e., the procedure 0)? Where should the standby get such a WAL file from?
> How?
I guess it would be perfectly sensible for 8.5, given the timeframe, to
not implement this as part of SR, but tell our users they need to make a
base backup themselves.
If after that the first WAL we need from the master ain't available, 8.5
SR should maybe only issue an ERROR with a HINT explaining how to ensure
not running in the problem when trying again.
But how we handle failures when transitioning from one state to the
other should be a lot easier to discuss and decide as soon as we have
the possible states and the transitions we want to allow and support. I
think.
My guess is that those states and transitions are in the code, but not
explicit, so that each time we talk about how to handle the error cases
we have to be extra verbose and we risk not talking about exactly the
same thing. Naming the states should make those arrangements easier, I
should think. Not sure if it would help follow the time constraint now
though.
Regards,
--
dim
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-01-14 19:39:21 | Re: EXPLAIN, utility statement parameters, and recent plpgsql changes |
Previous Message | Dimitri Fontaine | 2010-01-14 19:26:51 | Re: EXPLAIN, utility statement parameters, and recent plpgsql changes |