| From: | Josh Berkus <josh(at)agliodbs(dot)com> |
|---|---|
| To: | fazool mein <fazoolmein(at)gmail(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: xlog.c: WALInsertLock vs. WALWriteLock |
| Date: | 2010-10-26 19:00:05 |
| Message-ID: | 4CC72535.9020505@agliodbs.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2010-10-26 19:02:27 | Re: xlog.c: WALInsertLock vs. WALWriteLock |
| Previous Message | fazool mein | 2010-10-26 18:57:22 | Re: xlog.c: WALInsertLock vs. WALWriteLock |