Section 1 of 3 · 6 minutes

Define the change and its risk

Your goal

What you will be able to do

State the reason, exact scope, expected effect, dependencies, and failure modes for a PostgreSQL change.

Why this matters at work

The practical reason

A vague change cannot be tested, approved, verified, or rolled back reliably.

Learn

The idea in plain English

Write the current problem and the smallest proposed change. Name the databases, objects, settings, roles, application versions, and time window in scope.

List lock, storage, WAL, replication, restart, compatibility, and rollback risks that apply. Assign an owner and approval route before the maintenance window.

Remember these points

Make scope and expected effect measurable.
List dependencies and failure modes before the window.
Name the owner, approver, and stop conditions.

See it in SQL

Inspect a setting before a planned change

Record the current value, source, and rollout context for exact rollback.

SELECT
  name,
  setting,
  unit,
  context,
  source,
  sourcefile,
  pending_restart
FROM pg_settings
WHERE name = 'max_wal_size';

This captures the active value and where it came from. Keep it with the approved change record.

The context and pending-restart state determine whether reload, reconnect, or restart belongs in the rollout.

What you should see

The current max_wal_size value, source, file, change context, and pending-restart state.

Useful words

Important terms

Stop condition: A measured result that requires the rollout to pause or roll back.

Quick check · Not graded

Check your understanding

What makes a change scope testable?

Choose one answerIt names exact targets, expected results, timing, and stop conditions.It says only that PostgreSQL will be improved.It omits every dependency and owner.

Your progress is saved to your signed-in account.