-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
Le 14 déc. 08 à 16:48, Simon Riggs a écrit :
> I am truly lost to understand why the *name* "synchronous replication"
> causes so much discussion, yet nobody has discussed what they would
> actually like the software to *do* (this being a software discussion
> list...). AFAICS we can make the software behave like *any* of the
> definitions discussed so far.
It seems that the easy parts are the one the more people will
participate into. Maybe that's that simple.
> We can make the reply to a commit message when any of the following
> events have occurred
>
> 1. We sent the message to standby
> 2. We received the message on standby
> 3. We wrote the WAL to the WAL file
> 4. We fsync'd the WAL file
> 5. We CRC checked the WAL commit record
> 6. We applied the WAL commit record
Ok, so let's talk about this easy part: my understanding of
"synchronous replication" is that it gives to its users the strong
guarantee that at commit time the transaction is secured to the
slave(s). That means you get the D of ACID on more than one server.
Why synchronous? Because you know the durability is ensured exactly
when you receive the COMMIT ack.
So I'm with Simon on this, the term Synchronous Replication does
describe accurately what's being implemented here, and on the other
hand, as so many of us are saying, it's true that it tells very little
about it. Those 6 options are all in the scope of the infamous naming,
just different guarantees level, from almost strong to very strong,
with some "almost, but not quite, entirely unlike the strong I want".
Pick your naming here too.
At least, that's how I'm understanding this, the bottom line of why
care sending this email is that maybe it'll help some people to
recover from sleep deprivation ;)
My 2¢,
- --
dim
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
iEYEARECAAYFAklFcEsACgkQlBXRlnbh1bk0YwCfa+zGBKTK5EoH/Nmu0x+R6vKI
buAAniyL6Z+3MdT4rim5/xZQvdr4QOIQ
=iHnY
-----END PGP SIGNATURE-----
