Re: Sync Rep: First Thoughts on Code - Mailing list pgsql-hackers
From | Robert Haas |
---|---|
Subject | Re: Sync Rep: First Thoughts on Code |
Date | |
Msg-id | 603c8f070812132142n5408e7ddk899e83cddd4cb0b2@mail.gmail.com Whole thread Raw |
In response to | Re: Sync Rep: First Thoughts on Code ("Robert Haas" <robertmhaas@gmail.com>) |
Responses |
Re: Sync Rep: Second thoughts
Re: Sync Rep: First Thoughts on Code |
List | pgsql-hackers |
> The point here is that synchronous replication, at least to some > people, is going to imply that the user-visible states of the two > copies are consistent. To other people, it is going to imply that > committed transactions will never be lost even in the event of a > catastropic loss of the primary 1 picosecond after the commit is > acknowledged. We need to choose some word that implies that we are > guaranteeing the latter of these two things but not the former. > Otherwise, we will have confused users, and terminological confusion > when and if we ever implement the former as well. With apologies for replying to my own post: It's also important to understand that these two invariants are completely separate and it is possible to guarantee either without the other. If you want (1), the standby needs to apply the WAL before sending an acknowledgment to the primary but does not necessarily need to write it to disk (of course, it will have to be written to disk before the modified buffers are written to disk, but that's a separate issue). If you want (2), the standby needs to write the WAL to disk before sending the acknowledgment but does not necessarily need to apply it. If you want both, then, you need to wait for both (and it's worth noting that your performance will probably be nothing to write home about). I also did some research on terminology that has been used in the literature. As Jim Gray describes it: 1-safe replication. Transaction is committed when it has been locally WAL-logged to durable storage. Group-safe replication. Transaction is committed when WAL has been received by all remote servers, but not necessarily written to durable storage. Group-safe & 1-safe replication. Transaction is committed when it has been locally WAL-logged to durable storage and WAL has been received by all remote servers. 2-safe replication. Transaction is committed when it has been written to durable storage on both local and remote servers. Very safe replication. As 2-safe, but fails any read-write transaction if the secondary is down. (Actually, it appears that "Transaction Processing" Jim Gray and Andreas Reuter, 1993 uses 2-safe to refer to either 2-safe or group-safe; the distinction between the two is a subsequent development. See e.g. Advances in Database Technology-EDBT 2004 by Elisa Bertino) The term of art for making sure that transactions committed on the primary are visible on the secondary seems to be "one-copy serializability" (see, for example, a Google Books search on that term). ...Robert
pgsql-hackers by date: