Re: Synchronous Standalone Master Redoux - Mailing list pgsql-hackers

From Aidan Van Dyk
Subject Re: Synchronous Standalone Master Redoux
Date
Msg-id CAC_2qU89gFBuapR0n2rX1anUzazaQAXoUAdJEDCcfpuc6L_EqA@mail.gmail.com
Whole thread Raw
In response to Re: Synchronous Standalone Master Redoux  (Jose Ildefonso Camargo Tolosa <ildefonso.camargo@gmail.com>)
Responses Re: Synchronous Standalone Master Redoux
List pgsql-hackers
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,
aidan@highrise.ca                                       command like a king,
http://www.highrise.ca/                                   work like a slave.


pgsql-hackers by date:

Previous
From: Jose Ildefonso Camargo Tolosa
Date:
Subject: Re: Synchronous Standalone Master Redoux
Next
From: Joe Conway
Date:
Subject: Re: has_language_privilege returns incorrect answer for non-superuser