Critical Configuration

full_page_writes Disabled

The full_page_writes setting is disabled, risking torn page corruption after a crash that cannot be detected or repaired.

What is this issue?

When PostgreSQL modifies a page (8KB block), it first writes the entire
page to WAL before making the change. This protects against "torn pages"
where a crash occurs mid-write, leaving a page partially updated.

With full_page_writes = off:
- Torn pages can occur during crashes
- Data corruption may be silent and undetectable
- Backups may contain corrupted data
- Point-in-time recovery may fail

Why it matters

Undetectable Corruption

Torn pages may not be noticed until data is read

Propagating Damage

Corrupted pages get backed up and replicated

Recovery Failure

WAL replay can't fix torn pages without full page images

Data Loss

May require restoring from a very old backup

How PG Pilot detects it

```sql
SELECT name, setting, boot_val
FROM pg_settings
WHERE name = 'full_page_writes';
```

How to fix it

1

Enable full_page_writes immediately

This can be changed without restart:

ALTER SYSTEM SET full_page_writes = on;
SELECT pg_reload_conf();
2

Verify the change

Confirm the setting:

SHOW full_page_writes;
3

Take a fresh backup

If full_page_writes was off for any period, take a new base
backup immediately. Previous backups may contain silent corruption.

4

Consider data validation

Run pg_checksums (if enabled) or application-level validation
to check for existing corruption.

Prevention

  • Never disable full_page_writes in production
  • Use configuration management to enforce critical settings
  • Monitor configuration with PG Pilot
  • Only disable for benchmarking on disposable test data

Related Issues

Related Features

PostgreSQL Documentation