Re: Sync Rep: First Thoughts on Code - Mailing list pgsql-hackers

On Sat, 2008-12-13 at 13:05 -0500, Robert Haas wrote:
> > I certainly agree to using such terms. Unfortunately, in my experience,
> > synchronous replication is commonly used to mean that transactions are
> > guaranteed to be immediately visible on remote nodes after the client
> > got commit acknowledgment. That's the cause for confusion I'm envisioning.
> 
> I think that's a very important point.  It's very possible that 8.4
> may support both this feature and Hot Standby (although the latter
> seems to have stalled a bit...).  That makes me think "oh, great, I
> can offload any subset of my read-only queries to the standby".  Not
> so fast.
> 
> I think we need to reserve the term "synchronous replication" for a
> system where transactions that begin at the same time on the primary
> and standby see the same tuples.

Define "same time". 

You can have a variantof sync rep + hot standby where the master does
not return committed before the slave has both synced the data and
replied the transaction so that it is visible on slave but in that case
you may have a usecase, where it is actually visible on slave _before_
it is visible on master.

actually you can't have that "same time" guarantee even on single
system, that is, if you start two transactions connections "at the same
time", you still cant be sure there is not third transaction which has
committed between those two and which makes the visible data on those
two different.


>  Clearly that is "more" synchronous
> than what is being proposed here; if we call this "synchronous
> replication", what will we call that?  "Really Synchronous, Honest, No
> Kidding"?   Admittedly, we may never implement that feature, but that
> seems irrelevant.
> 
> It would be useful to have names for all the different possibilities.
>  Random ideas:
> 
> Log Shipping.  After each log switch, the previous WAL log is copied
> to the standby in its entirety.
> 
> WAL Streaming - Asynchronous.  The WAL log is streamed from master to
> standby as it is written, but transactions on the master never wait.
> 
> WAL Streaming - Synchronous Receive.  The WAL log is streamed from
> master to standby as it is written, and transactions on the master
> wait until the standby acknowledges receipt of the WAL.
> 
> WAL Streaming - Synchronous Write.  The WAL log is streamed from
> master to standby as it is written, and transactions on the master
> wait until the standby acknowledges that the WAL has been written to
> disk.
> 
> WAL Streaming - Synchronous Apply.  The WAL log is streamed from
> master to standby as it is written, and transactions on the master
> wait until the standby acknowledges that WAL has been written to disk
> and applied.

We still could call Sync Rep as a feature "synchronous replication" on
basis that "WAL Streaming - Synchronous Write" is the highest security
level achievable using the feature.

And maybe have Sync Hot Standby as a feature on top of that which
provides "WAL Streaming - Synchronous Apply"



------------------------------------------
Hannu Krosing   http://www.2ndQuadrant.com
PostgreSQL Scalability and Availability   Services, Consulting and Training