On Mon, Jun 14, 2010 at 10:13 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Mon, Jun 14, 2010 at 8:41 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
>> On Mon, Jun 14, 2010 at 8:10 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>>> Maybe. That sounds like a pretty enormous foot-gun to me, considering
>>> that we have no way of recovering from the situation where the standby
>>> gets ahead of the master.
>>
>> No, we can do that by reconstructing the standby from the backup.
>>
>> And, that situation is not a problem for users including me who prefer to
>> perform a failover when the master goes down.
>
> You don't get to pick - if a backend crashes on the master, it will
> restart right away and come up, but the slave will now be hosed...
You are concerned about the case where postmaster automatically restarts
the crash recovery, in particular? Yes, this case is more problematic.
If the standby is ahead of the master, the standby might find an invalid
record and run into the infinite retry loop, or keep working without
noticing the inconsistency between the database and the WAL.
I'm thinking that walreceiver should throw a PANIC when it receives the
record which is in the LSN older than the last WAL receive location,
except the beginning of streaming (because the standby always requests
for streaming from the starting of WAL file at first even if some records
have already been received in previous time). Thought?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center