On Wed, Oct 13, 2010 at 10:18 PM, Greg Stark <gsst...@mit.edu> wrote: > On Tue, Oct 12, 2010 at 11:50 PM, Robert Haas <robertmh...@gmail.com> wrote: >> There's another problem here we should think about, too. Suppose you >> have a master and two standbys. The master dies. You promote one of >> the standbys, which turns out to be behind the other. You then >> repoint the other standby at the one you promoted. Congratulations, >> your database is now very possible corrupt, and you may very well get >> no warning of that fact. It seems to me that we would be well-advised >> to install some kind of bullet-proof safeguard against this kind of >> problem, so that you will KNOW that the standby needs to be re-synced. >> I mention this because I have a vague feeling that timelines are >> supposed to prevent you from getting different WAL histories confused >> with each other, but they don't actually cover all the cases that can >> happen. >> > > Why don't the usual protections kick in here? The new record read from > the location the xlog reader is expecting to find it has to have a > valid CRC and a correct back pointer to the previous record. If the > new wal sender is behind the old one then the new record it's sent > won't match up at all.
There's some kind of logic that rewinds to the beginning of the WAL segment and tries to replay from there. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
