Re: xlog.c: WALInsertLock vs. WALWriteLock - Mailing list pgsql-hackers

From Josh Berkus
Subject Re: xlog.c: WALInsertLock vs. WALWriteLock
Date
Msg-id 4CC72535.9020505@agliodbs.com
Whole thread Raw
In response to Re: xlog.c: WALInsertLock vs. WALWriteLock  (fazool mein <fazoolmein@gmail.com>)
Responses Re: xlog.c: WALInsertLock vs. WALWriteLock
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: xlog.c: WALInsertLock vs. WALWriteLock
Next
From: Robert Haas
Date:
Subject: Re: xlog.c: WALInsertLock vs. WALWriteLock