@mark1russell7/machines 0.3.9 → 0.3.11

package/README.md

@@ -46,8 +46,10 @@ The algebra reads these documents. It gives the closed form of each timer, the f
 | `PGBOUNCER_CLIENT` | `pgbouncer-client` | PgBouncer 1.26.1 in transaction pooling: one client connection | proxy | 29 implemented |
 | `PGBOUNCER_SERVER` | `pgbouncer-server` | PgBouncer 1.26.1 in transaction pooling: one server connection of a pool | proxy | 26 implemented |
 | `PGPOOL_SESSION` | `pgpool-session` | Pgpool-II 4.7.3 with one backend: one session of a client in its child process | proxy | 15 implemented |
+| `SUPAVISOR_CLIENT` | `supavisor-client` | Supavisor 2.9.13 in transaction mode: one client connection | proxy | 15 implemented |
+| `SUPAVISOR_SERVER` | `supavisor-server` | Supavisor 2.9.13 in transaction mode: one server connection of the pool of a tenant | proxy | 10 implemented, 1 observed |
 
-Seventeen documents operate on Linux TCP (`over`). Linux TCP, conntrack, the Sentinel and the replication of mongod operate on no other document. The `conditions` of each document give the range where it holds, for example a range of kernels.
+Nineteen documents operate on Linux TCP (`over`). Linux TCP, conntrack, the Sentinel and the replication of mongod operate on no other document. The `conditions` of each document give the range where it holds, for example a range of kernels.
 
 The package also gives these parts:
 
@@ -93,6 +95,18 @@ A change to the version of a system changes its sources too. Each fact of the do
 
 In this repository, a snapshot of the predictions of the cells (`packages/cells/src/__snapshots__/predictions.json`) shows each prediction that a change to a document moves.
 
+### 0.3.11
+
+- **The connect timer of PgBouncer can fire early.** libevent 2.1 counts a timeout from its cached time of the pass, not from the clock (event.c, `event_add_nolock` with `gettime` and `tv_cache`). Thus server_connect_timeout can fire up to one pass early, and its band has an early slack of 10 ms. In run 39160356281 the timer closed the socket at 127.998993 s, 1.007 ms before 128 s.
+
+### 0.3.10
+
+- **Supavisor 2.9.13, in transaction mode.** Two new documents, each from the Elixir source at the tag v2.9.13:
+  - `supavisor-client`: one client connection. Between two transactions the client holds no server connection, thus a fault of the server reaches an idle client only through the pool. At the defaults Supavisor writes a heartbeat to an idle client each 60 s. A checkout waits up to 15 s for a server connection, then FATAL XX000. Each client socket has SO_KEEPALIVE.
+  - `supavisor-server`: one server connection of the pool. The connect has a timeout of 5 s, and a failed connect gives FATAL 08006 to a client that waits for it. The next connect of the pool waits the rest of 2.5 s. The server socket has no keepalive.
+  - A server that shuts down can end each idle client of the tenant. When a login of the pool gets 57P03, Supavisor shuts the pool down gracefully: each client outside a transaction gets FATAL 57P01 and its close. In run 39164922565 that came in 6 of 11 runs, and the other 5 met a refused connect, which keeps the pool.
+  - In 2.9.13, client_idle_timeout ends no session. Its timer fires an event that no clause of the client handler takes, thus the document gives it no timer.
+
 ### 0.3.9
 
 - **The SYN give-up of Linux TCP has its lateness.** Each wait of the SYN is a timer of the wheel, which rounds it up at its level. At the defaults and HZ 1000, the wait of 64 s can be 4.096 s late. Thus the give-up is 131 s to 137.08 s. At HZ 250 it is up to 5.056 s late. The lateness needs `@mark1russell7/algebra` 0.7.2.

package/build/index.d.ts

@@ -269,6 +269,39 @@ export declare const PGPOOL_SESSION: Machine;
  */
 export declare const POSTGRES_SESSION: Machine;
 //#endregion
+//#region src/pg/supavisor-client.d.ts
+/**
+ * This document is Supavisor 2.9.13 in transaction mode, for one client connection. It gives the
+ * states of the client handler (a gen_statem) from the accept to the close, and the timers that act
+ * on it.
+ *
+ * Between two transactions the client holds no server connection. A message of the client checks one
+ * out of the pool of the tenant, and ReadyForQuery of the server checks it in. Thus a fault of the
+ * server reaches an idle client only through the pool. Its next query meets the pool, or the pool
+ * shuts down and closes it, as after 57P03 at a login of the pool.
+ *
+ * At the defaults the handler writes a heartbeat to an idle client each 60 s: a ParameterStatus of
+ * application_name. A failed write ends the client. client_idle_timeout does not end a session in
+ * 2.9.13: its timer fires an event that no clause handles. Each client socket has SO_KEEPALIVE.
+ */
+export declare const SUPAVISOR_CLIENT: Machine;
+//#endregion
+//#region src/pg/supavisor-server.d.ts
+/**
+ * This document is Supavisor 2.9.13 in transaction mode, for one server connection of the pool of a
+ * tenant. It is one DbHandler, a gen_statem, from its start by the pool to its end.
+ *
+ * The connect to the server has a timeout of 5 s, and the authentication 15 s. A failed connect ends the
+ * DbHandler with FATAL 08006 'Failed to connect to database'. A client that waits for this connection gets
+ * that error at once. The pool then starts a new DbHandler, which waits the rest of 2.5 s from the last
+ * failure before it connects.
+ *
+ * The DbHandler reads its socket in each state. Thus a close or a reset of the server ends it at once, idle
+ * or with a client. A client that holds the connection then gets the close. The server socket has
+ * TCP_NODELAY and no keepalive, and no timer of Supavisor bounds a query.
+ */
+export declare const SUPAVISOR_SERVER: Machine;
+//#endregion
 //#region src/procedures-ws.d.ts
 /**
  * This document is the connection of the WebSocket client of `@procedures/client` 0.3.0