Distributed Services with Go: "atomic" Append() (page 27)

Edit: After reading more of the book, this doesn’t seem to be an issue (see replies).

The “Append” function on the store splits writing the record size and the record itself into two separate writes. If the server were to crash between these writes the store file would be corrupted because, once the server starts up again the first Append will result in two sizes in a row.

Would it be better for this code to write the record size and the record all at once, in one call to either s.buf.Write or binary.Write?

1 Like

Oh, I see there’s a note page 34 about not handling ungraceful shutdowns. I imagine that disclaimer covers this case.

Additionally, because of the way the segment Append coordinates the store and index Appends, this shouldn’t be an issue in practice – data might get lost but that is probably more of a client, rather than server, issue.

Yeah the code should be synchronized so we don’t have partial writes. But if we don’t finish a write then that’s OK, especially later on in the project and book when we add consensus, and the client can always retry a produce call if the request fails.