On Thu, Jul 12, 2012 at 8:27 PM, Jose Ildefonso Camargo Tolosa > Yeah, you need that with PostgreSQL, but no with DRBD, for example > (sorry, but DRBD is one of the flagships of HA things in the Linux > world). Also, I'm not convinced about the "2nd standby" thing... I > mean, just read this on the docs, which is a little alarming: > > "If primary restarts while commits are waiting for acknowledgement, > those waiting transactions will be marked fully committed once the > primary database recovers. There is no way to be certain that all > standbys have received all outstanding WAL data at time of the crash > of the primary. Some transactions may not show as committed on the > standby, even though they show as committed on the primary. The > guarantee we offer is that the application will not receive explicit > acknowledgement of the successful commit of a transaction until the > WAL data is known to be safely received by the standby." > > So... there is no *real* warranty here either... I don't know how I > skipped that paragraph before today.... I mean, this implies that it > is possible that a transaction could be marked as commited on the > master, but the app was not informed on that (and thus, could try to > send it again), and the transaction was NOT applied on the standby.... > how can this happen? I mean, when the master comes back, shouldn't the > standby get the missing WAL pieces from the master and then apply the > transaction? The standby part is the one that I don't really get, on > the application side... well, there are several ways in which you can > miss the "commit confirmation": connection issues in the worst moment, > and the such, so, I guess it is not *so* serious, and the app should > have a way of checking its last transaction if it lost connectivity to > server before getting the transaction commited.
But you already have that in a single server situation as well. There is a window between when the commit is "durable" (and visible to others, and will be committed after recovery of a crash), when the client doesn't yet know it's committed (and might never get the commit message due to server crash, network disconnect, client middle-tier crash, etc). So people are already susceptible to that, and defending against it, no? ;-) And they are susceptible to that if they are on PostgreSQL, Oracle, MS SQL, DB2, etc. a. -- Aidan Van Dyk Create like a god, ai...@highrise.ca command like a king, http://www.highrise.ca/ work like a slave. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
