Re: xlog.c: WALInsertLock vs. WALWriteLock
От | Robert Haas |
---|---|
Тема | Re: xlog.c: WALInsertLock vs. WALWriteLock |
Дата | |
Msg-id | AANLkTinAroFJnL4sAER8Z3c24Na0Qwc38QNUGiMdGn=8@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: xlog.c: WALInsertLock vs. WALWriteLock (Josh Berkus <josh@agliodbs.com>) |
Список | pgsql-hackers |
On Tue, Oct 26, 2010 at 3:00 PM, Josh Berkus <josh@agliodbs.com> wrote: > >> 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. Agreed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: