Re: xlog.c: WALInsertLock vs. WALWriteLock

Поиск
Список
Период
Сортировка
От Josh Berkus
Тема Re: xlog.c: WALInsertLock vs. WALWriteLock
Дата
Msg-id 4CC72535.9020505@agliodbs.com
обсуждение исходный текст
Ответ на Re: xlog.c: WALInsertLock vs. WALWriteLock  (fazool mein <fazoolmein@gmail.com>)
Ответы Re: xlog.c: WALInsertLock vs. WALWriteLock  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
> I agree that the standby might get ahead, but this doesn't necessarily
> lead to database corruption. Here, the interesting case is what happens
> when the primary fails, which can lead to *either* of the following two
> cases:
> 1) The standby, due to some triggering mechanism, becomes the new
> primary. In this case, even if the standby was ahead, its fine.
> 2) The primary comes back as primary. In this case, the standby will
> connect again to the primary. At this point, *if* somehow we are able to
> detect that the standby is ahead, then we should abort the standby and
> create a standby from scratch.

Yes.  And we weren't able to implement that for 9.0.  It's worth
revisiting for 9.1.  In fact, the issue of "is the standby ahead of the
master" has come up repeatedly in potential failure scenarios; I think
we're going to need a fairly bulletproof method to determine this.

--                                  -- Josh Berkus                                    PostgreSQL Experts Inc.
                        http://www.pgexperts.com
 


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: xlog.c: WALInsertLock vs. WALWriteLock
Следующее
От: Robert Haas
Дата:
Сообщение: Re: xlog.c: WALInsertLock vs. WALWriteLock