Created Started Cancelled
By: Tom Sydney Kerckhove <syd@cs-syd.eu>
Let a postgresql suite have a real read replica An application that offloads reads onto a read replica is an application whose reads can be older than its writes, and nothing in this library could say so: the server it starts has no replica, so a read that must not be answered by one looks exactly like a read that may be. Start a real standby instead of standing in for one. pg_basebackup into a directory of its own, a replication slot, hot standby, torn down with the suite. It replays the same write-ahead log a production replica does, in the same order, and refuses writes because postgres refuses them. recovery_min_apply_delay is what makes being behind a fact rather than a race: without it a local standby follows fast enough that whether a read sees a just-committed write depends on the machine. What that needs from the server is wal_level = replica, which tmp-postgres' defaultConfig does not give (it asks for minimal, which writes too little to the log for anything to replay). So the config becomes the caller's to choose, through postgresqlServerSetupFuncWith and persistPostgresqlAdminSpecWith, with replicationPrimaryConfig for the case this is all for. replicatedPoolsSetupFunc is the pair such an application is configured with: a fresh database, a pool to it on the primary, and a pool to the same database on the standby. Waiting for the database to appear on the standby is part of it, because until the creation is replayed there is no database there to connect to. How far behind the standby is belongs to the cluster, not to a database, so a test sharing that cluster cannot pause replay or change the delay for itself alone. The one control that is safe to hand a single test is waiting, so that is the only one there is.