eec7d47f

By: Tom Sydney Kerckhove <syd@cs-syd.eu>

Give the read replica an API worth using

The first cut made a caller thread two outer resources, know that a
standby needs a specially configured primary, and pass that config
themselves.  Forgetting it failed at runtime.  Eleven names for one
idea.

Writing a test against a replica should cost what writing one without
costs, because what a suite pays for a replica is finding out what its
application does when its reads are older than its writes, not a
harder test to write.  So:

  spec = persistPostgresqlSpec migration $         spec = persistPostgresqlReplicatedSpec migration $
    it "..." $ \pool -> do                           it "..." $ \pools -> do
      i <- runPostgresqlTest pool $ insert p           i <- asOfLongAgo pools $ onPrimary pools $ insert p
      mp <- runPostgresqlTest pool $ get i             mp <- onReplica pools $ get i

Same shape, no outer resources, no config to pass.  The one thing the
replica version says that the other does not is the one thing that is
actually different about it: which part of the test happened long ago.

ReplicatedPools is two plain fields now, and waiting is a function
over them rather than an action stored inside.  That is what lets
unreplicatedPools be the whole answer for an application configured
without a replica: awaitReplica returns at once when what it is given
is not a standby, so the same test body works either way.

The lag is a NominalDiffTime rather than a string spelled the way
postgres spells intervals, and it has a default.  Twenty milliseconds,
which is what a replica keeping up looks like: the tempting setting is
a large one, on the grounds that it is harsher, and it is milder.  A
replica far enough behind to have replayed nothing answers every read
with a clean miss, and a clean miss is the case an application
handles.

Total

5m08s

Created 1 month ago Started 1 month ago Finished 1 month ago

Timeline