# 4.1.1 The Loose Handshake (Commit Tuning)
In Postgres, safety is the most expensive thing you can buy. As we’ve seen, the **`fsync()`** handshake—waiting for the physical disk to confirm it has etched every record—is the primary bottleneck for write-heavy workloads.
If your application needs to handle thousands of orders per second, you must decide how "tight" your handshake needs to be.
## The Loose Handshake: `synchronous_commit`
The most impactful WAL tweak is the **`synchronous_commit`** setting. By default, it is set to `on`, meaning Postgres will not tell a client "Done" until the WAL record is guaranteed to be on physical storage.
But what if you value speed over absolute durability for specific operations?
### `synchronous_commit = off`
When you set this to `off`, you are performing a **Loose Handshake**. Postgres will commit the transaction in memory, give the user a thumbs up, and continue—but it will *not* wait for the WAL record to be `fsync`'d to disk.
The **WAL Writer** process will eventually flush the data in the background (usually within 3x `wal_writer_delay`, or about 600ms by default).
- **The Reward**: Massive throughput gains. On standard hardware, switching to `off` can often triple the number of transactions per second.
- **The Risk**: If the server crashes or the OS fails before the background flush happens, you can lose up to ~0.6 seconds of data.
- **The Safety Net**: Crucially, setting this to `off` **cannot cause data corruption**. The database remains physically consistent because the WAL records are still written in the correct order—you only risk losing the most recent history.
> [!TIP]
> You don't have to change this globally. You can set `synchronous_commit = off` for a single session or even a single transaction:
> ```sql
> BEGIN;
> SET LOCAL synchronous_commit = off;
> INSERT INTO supply_deliveries (...) VALUES (...);
> COMMIT;
> ```
## The Group Rush: Tuning Group Commit
If you choose to keep safety `on`, you can still optimize performance by helping Postgres aggregate its work. This is managed by two settings:
### 1. `commit_delay`
This tells the engine to wait for a specific number of microseconds before performing an `fsync()`.
- **The Logic**: It’s like a waiter waiting an extra 5 seconds at the kitchen door to see if any other orders are ready so they only have to make one trip.
- **Value**: Defaults to `0`. Setting it to something like `1000` (1ms) can improve throughput during high-concurrency bursts.
### 2. `commit_siblings`
This is a guardrail for `commit_delay`. It specifies how many *other* concurrent transactions must be active before `commit_delay` is invoked.
- **The Logic**: There’s no point in waiting if you’re the only person in the Cafe. If there are fewer than `commit_siblings` active transactions, the engine ignores the delay and flushes immediately.
## The Scribble Memory: `wal_buffers`
Before WAL records hit the disk, they sit in the **WAL Buffers** (the mental scratchpad).
By default, this is set to `-1`, which tells Postgres to automatically allocate 1/32 of your **`shared_buffers`** (up to 16MB). For almost all workloads, this auto-tuning is perfect. However, if you are seeing wait events like `WALBuffer-Full`, increasing this can prevent the engine from stalling while waiting for the WAL writer to catch up.
> [!IMPORTANT]
> **Summary of Commit Levels**:
> - **`on`**: The default. Wait for local disk flush.
> - **`off`**: Do not wait for disk. Best for performance where minor data loss is acceptable.
> - **`local`**: Used in replication (see Chapter 7). Wait for local flush but not replica flush.
> - **`remote_write`**: Wait for replica to receive data but not necessarily flush it.
> - **`remote_apply`**: Wait for replica to physically apply the change to its own files.
---
| ← Previous | ↑ Table of Contents | Next → |
| :--- | :---: | ---: |
| [[Chapter 4/4.1 - The Pocket Diary (WAL & fsync)\|4.1 The Pocket Diary (WAL & fsync)]] | [[Learn You a Postgres for Great Good\|Home]] | [[Chapter 4/4.2 - The Recovery Parade (Crash Recovery)\|4.2 The Recovery Parade (Crash Recovery)]] |