-
Notifications
You must be signed in to change notification settings - Fork 4
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
chore: remove ack logic from the client as unused (#392)
This PR simplifies the client by removing `_lastAck` and `_lastSent` from the process, and `ack_lsn` from the outbound replication state in the client. There are three parts to validity of these changes: 1. `this.outbound.ack_lsn` in the client was just unused. It was assigned in a bunch of places, but read only in one function (`getOutboundLogPositions`), where the only calling place (`SatelliteProcess#_performSnapshot`) didn't use that part of the return value. This PR removes this field, and simplifies function signatures appropriately. 2. `_lastSentRowId` in the client was set in a lot of places as well, but only usage place was to fill `client.outbound.enqueued_lsn`. This allowed the client to continue streaming to the server from the LSN it didn't sent before, however that logic is incorrect: `SatInStartReplicationReq` message sent by the server has an LSN in it which is the actual LSN the client is expected to start from - current code just didn't respect this (because of a bug in the server that didn't actually set that field correctly, which is also fixed in this PR). Correct behaviour is to keep track of enqueued LSN only for the lifetime of the client connection, because on reconnect server will tell the client where to start from - which makes keeping `_lastSentRowId` useless. This PR removes this field, as well as the preset row in the meta table with `lastSentRowId` key. 3. `_lastAckdRowId` is the most complicated to explain. 1. It was set based on the pings from the server, which are currently incorrect. There are changes in #386 which fix the acknowledges on the server to be only done on actual persistence to Postgres. If Electric had reached the transaction saving the persisted position to Postgres, that means it reached the original sent transaction itself and is about to send it out to clients. Hence, there is no difference in time between receiving the acknowledge and the transaction itself after the round-trip. 2. The queries in `_performSnapshot` used `rowid > _lastAckdRowId` check in all queries, but if have received back the original transaction, we have already deleted the irrelevant oplog entries. Furthermore, queries have equality checks on `timestamp` column that made `rowid` checks useless regardless of other context. 3. The other place where `_lastAckdRowId` was used, was in `_apply` call, which called `this._getEntries()`. `this._getEntries()` without arguments used to do a query with `rowid > _lastAckdRowId` to avoid including acknowledged rows in conflict resolution, however, as described above, any acknowledged rows can be safely considered garbage collected. _This is actually more correct now, because before we receive back the transaction and GC the oplog entry, all other transactions came before ours from Postgres point of view, and to replicate conflict resolution exactly we should use all oplog entries regardless if the server has seen them, persisted them, or whatever._ So this PR makes it so we rely only on GC of oplog for all queries, removes `_lastAckdRowId` property, as well as the preset row in the meta table with `lastAckdRowId` key. There is a follow-up to be made that we don't actually use ping data neither on the client nor on the server, but that's a separate PR. --------- Co-authored-by: Valter Balegas <[email protected]>
- Loading branch information
1 parent
1b24995
commit d22630c
Showing
13 changed files
with
146 additions
and
331 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.